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

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith 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) {
----------------
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)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88220