[PATCH] D88220: [C++20] P1825R0: More implicit moves
Arthur O'Dwyer via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Mon Dec 7 05:48:39 PST 2020
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
More information about the cfe-commits
mailing list