[PATCH] D88220: [C++20] P1825R0: More implicit moves

[David Stone via Phabricator via cfe-commits]

davidstone added inline comments.


================
Comment at: clang/test/CXX/class/class.init/class.copy.elision/p3.cpp:22
+  return c;
+}
+#else
----------------
Quuxplusone wrote:
> Quuxplusone wrote:
> > @rsmith @david_stone (or anyone), what is the status in C++20 of the following test case?
> > 
> >     C&& test(C&& c) {
> >         return c;
> >     }
> > 
> > I know we talked about this in person at CppCon 2018, and concluded that our //intention// was for this to be legal, but that it wasn't actually legal as-worded, because the returned thingie here is not an object but rather a reference, and therefore none of [P1825's](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1825r0.html) wording actually covers it. Is that still the case? Is there an open issue about this? Is there any appetite for Clang to just go ahead and //make// this legal?  (The current patch does //not// make this legal.)
> > 
> > Relevant reading: https://quuxplusone.github.io/blog/2018/09/25/perfect-backwarding/
> Apparently @davidstone has been active more recently than @david_stone... :)
Going through the wording in http://eel.is/c++draft/class.copy.elision#3

"An implicitly movable entity is a variable of automatic storage duration that is either a non-volatile object or an rvalue reference to a non-volatile object type."

So we are fine with a reference as the source. However, it then goes on to say

"...overload resolution to select the constructor for the copy or the return_­value overload to call is first performed as if the expression or operand were an rvalue."

There is technically no constructor to call here, which I think means this section does not apply.

I don't believe an issue has been raised for this yet, so I'll email CWG about it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88220/new/

https://reviews.llvm.org/D88220