llvm dev - Sep 2020 - preferred way to return expected values

Hello everyone!
It looks like in the LLVM codebase (including subprojects) there are some
inconsistencies
in how values are returned from functions with the following (or similar)
signature:
    Expected<std::vector<int>> createVector() {
        std::vector<int> V;
        ...
    }
It would be interesting to find out your opinion on this.
After some investigation I have found https://reviews.llvm.org/D70963 and
https://reviews.llvm.org/D43322 which have some additional context
regarding
the problem. The aforementioned diffs (and the comments on them) contain a
lot of
details and the history of the problem (whether one should use the cast or
not).
If I am not mistaken a part of the problem is that compilers' behaviors
have changed over time, and e.g. the latest versions would use a move
constructor while the older ones could use a copy constructor. So the
question is where we stand at the moment / what is the recommended approach
for the new code.

Many thanks in advance,
Alexander Shaposhnikov
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200926/1e5bff04/attachment.html>

To clarify, this is a discussion around whether given some move-only type
X, implicitly convertible to Y and the code "Y func() { X x; return x;
}"
is that valid in LLVM? (and, as a corollary, if the type isn't move-only,
is that code efficient (does it move rather than copying) - as in the
vector example given)

I /believe/ the answer is that it is not valid. I think the set of
compilers supported includes those that do not implement this rule. (either
due to the language version we compile with, or due to it being a DR that
some supported compiler versions do not implement). But that's just my
rough guess.

On Sat, Sep 26, 2020 at 3:17 PM Alexander Shaposhnikov via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hello everyone!
> It looks like in the LLVM codebase (including subprojects) there are some
> inconsistencies
> in how values are returned from functions with the following (or similar)
> signature:
>     Expected<std::vector<int>> createVector() {
>         std::vector<int> V;
>         ...
>     }
> It would be interesting to find out your opinion on this.
> After some investigation I have found https://reviews.llvm.org/D70963 and
> https://reviews.llvm.org/D43322 which have some additional context
> regarding
> the problem. The aforementioned diffs (and the comments on them) contain a
> lot of
> details and the history of the problem (whether one should use the cast or
> not).
> If I am not mistaken a part of the problem is that compilers' behaviors
> have changed over time, and e.g. the latest versions would use a move
> constructor while the older ones could use a copy constructor. So the
> question is where we stand at the moment / what is the recommended approach
> for the new code.
>
> Many thanks in advance,
> Alexander Shaposhnikov
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200928/a6842994/attachment.html>

Many thanks for the reply,
right, this is what the discussion is about.


On Mon, Sep 28, 2020 at 10:57 AM David Blaikie <dblaikie at gmail.com>
wrote:
> To clarify, this is a discussion around whether given some move-only type
> X, implicitly convertible to Y and the code "Y func() { X x; return x;
}"
> is that valid in LLVM? (and, as a corollary, if the type isn't
move-only,
> is that code efficient (does it move rather than copying) - as in the
> vector example given)
>
> I /believe/ the answer is that it is not valid. I think the set of
> compilers supported includes those that do not implement this rule. (either
> due to the language version we compile with, or due to it being a DR that
> some supported compiler versions do not implement). But that's just my
> rough guess.
>
> On Sat, Sep 26, 2020 at 3:17 PM Alexander Shaposhnikov via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hello everyone!
>> It looks like in the LLVM codebase (including subprojects) there are
some
>> inconsistencies
>> in how values are returned from functions with the following (or
similar)
>> signature:
>>     Expected<std::vector<int>> createVector() {
>>         std::vector<int> V;
>>         ...
>>     }
>> It would be interesting to find out your opinion on this.
>> After some investigation I have found https://reviews.llvm.org/D70963
>> and https://reviews.llvm.org/D43322 which have some additional context
>> regarding
>> the problem. The aforementioned diffs (and the comments on them)
contain
>> a lot of
>> details and the history of the problem (whether one should use the cast
>> or not).
>> If I am not mistaken a part of the problem is that compilers'
behaviors
>> have changed over time, and e.g. the latest versions would use a move
>> constructor while the older ones could use a copy constructor. So the
>> question is where we stand at the moment / what is the recommended
approach
>> for the new code.
>>
>> Many thanks in advance,
>> Alexander Shaposhnikov
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200928/0ddd5007/attachment.html>