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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
