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

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

Quuxplusone added inline comments.


================
Comment at: clang/lib/Sema/SemaStmt.cpp:3226-3227
+    CopyElisionSemanticsKind CESK = CES_Strict;
+    if (getLangOpts().CPlusPlus20) {
+      CESK = CES_ImplicitlyMovableCXX20;
+    } else if (getLangOpts().CPlusPlus11) {
----------------
rsmith wrote:
> Quuxplusone wrote:
> > rsmith wrote:
> > > P1825 was accepted as a Defect Report (see https://wiki.edg.com/bin/view/Wg21cologne2019/StrawPolls); is there a reason we're not applying this retroactively?
> > > Move to accept the changes in P1825R0 (Merged wording for P0527R1 and P1155R3) as a Defect Report and apply them to the C++ working paper.
> > 
> > Yipes. @rsmith, is the intent that modern compilers should support
> > ```
> > std::unique_ptr<int> from_rvalue(std::unique_ptr<int>&& x) { return x; }
> > ```
> > in `-std=c++11` mode? Are Clang, GCC, MSVC, EDG all on the same page here? If so, awesome. I just find it a priori unlikely that we got informed consensus on that.
> Yes, the intent is that P1825 should be applied all the way back to C++11. See the CWG discussion here: https://wiki.edg.com/bin/view/Wg21cologne2019/CoreWorkingGroup#D1825R0_Merged_wording_for_P_AN1 -- in which we concluded that the entire paper should be treated as a DR.
> 
> Regarding implementation consensus: MSVC already implements the changes in all language modes (since v19.24). It looks like the intent is for GCC to do the same in GCC 12 onwards (https://github.com/gcc-mirror/gcc/commit/1722e2013f05f1f1f99379dbaa0c0df356da731f). I'm not sure what EDG's plans are.
> 
> I think for us the question is whether we can get away with doing this without any kind of transition period. If extending this all the way back to C++11 is disruptive in practice for existing code, we may need to take a more measured approach, such as phasing the introduction of this over a couple of Clang releases with warnings for things that will change behavior, but if not, I think we should just do it (and there's no better way to find out how disruptive this is than doing it...). We might actually need to implement P2266 as well, in order to avoid regressions such as the one that Jason mentioned in that GCC commit message; I suppose we'll find out.
> 
> I wonder whether we can extend this back to C++98 (and thereby have the same rules regardless of language standard). If someone is using rvalue references in C++98 (which we allow as an extension) it seems to make sense for the new behavior to apply to them. Are there cases where the new rules would affect the meaning of a standard C++98 program (ie, one that has no move constructors, no rvalue reference parameters, and so on)?
>From Godbolt: MSVC implements all parts of p1825 in C++17 mode.
>From that patch, and Godbolt: GCC trunk implements some subtle variation of p1155 (but specifically //no part of// p0527) in C++17 mode.

> Are there cases where the new rules would affect the meaning of a standard C++98 program (ie, one that has no move constructors, no rvalue reference parameters, and so on)?

Yes, Jason Merrill's example is specifically about p1155's effect on a pathological C++98 type, which I call `AutoSharePtr` in my C++Now 2021 talk "The Complete Guide to return x". I will start recommending that people watch that talk, as soon as it hits YouTube. :)  https://godbolt.org/z/T374o518W


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88220