[llvm-dev] preferred way to return expected values

[David Blaikie via llvm-dev]

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>