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