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

[Arthur O'Dwyer via Phabricator via cfe-commits]

Quuxplusone added inline comments.


================
Comment at: clang/include/clang/Sema/Sema.h:4626
     CES_AllowExceptionVariables = 4,
-    CES_FormerDefault = (CES_AllowParameters),
-    CES_Default = (CES_AllowParameters | CES_AllowDifferentTypes),
-    CES_AsIfByStdMove = (CES_AllowParameters | CES_AllowDifferentTypes |
-                         CES_AllowExceptionVariables),
+    CES_AllowRValueReferenceType = 8,
+    CES_ImplicitlyMovableCXX11CXX14CXX17 =
----------------
nullptr.cpp wrote:
> Quuxplusone wrote:
> > I believe `RValue` should be spelled `Rvalue`, throughout.
> There are already names such as `RValueReferenceType`, so be consistent with existing code.
Okay, I see examples both ways and wish there were one standard spelling, but I agree there's no standard at the moment, so whatever.


================
Comment at: clang/test/CXX/class/class.init/class.copy.elision/p3.cpp:28
+private:
+  C(C &&); // cxx20-note {{declared private here}}
+};
----------------
nullptr.cpp wrote:
> [over.match.funcs]p8:
> > A defaulted move special member function that is defined as deleted is excluded from the set of candidate functions in all contexts.
> 
> So in this case still use private.
If it's user-declared as deleted, then it is not defaulted.
To get a move-constructor that is defaulted as deleted, you'd have to write something like https://godbolt.org/z/KbG76v (Notice how the behavior changes if you explicitly delete it with `C(C&&) = delete;` instead of implicitly deleting it with `C(C&&) = default;`.)


================
Comment at: clang/test/CXX/class/class.init/class.copy.elision/p3.cpp:22
+  return c;
+}
+#else
----------------
davidstone wrote:
> 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.
I don't know if there's a CWG issue number (yet?) but at least I have drafted a paper, [D2266R0](http://quuxplusone.github.io/draft/d2266-implicit-move-rvalue-ref.html), on the subject. @nullptr.cpp could you take a look at this paper and let me know (perhaps by email) what you think about it?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88220