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