[llvm-dev] preferred way to return expected values

Alexander Shaposhnikov via llvm-dev llvm-dev at lists.llvm.org
Mon Sep 28 12:46:20 PDT 2020


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>


More information about the llvm-dev mailing list