[PATCH] D104500: [clang] Apply P1825 as Defect Report from C++11 up to C++20.

[Louis Dionne via Phabricator via cfe-commits]

ldionne added a comment.

In D104500#2865917 <https://reviews.llvm.org/D104500#2865917>, @mizvekov wrote:

> Well I thought that meant exactly that libc++ does not support C++98, it only works on clang because it provides so much of C++11 as an extension.
>
> I did not remove this just on my own whim by the way, the information I had and the reason the patch was approved as is, is because as I said, those extensions were considered best effort and not officially supported.
> @rsmith thoughts?

I don't know what the state of those extensions is from Clang's perspective, however one thing is clear - we use those extensions in libc++ very heavily. If any such extension is removed, libc++ will stop working in C++03 mode, which effectively means that most of the code compiled with Clang is going to break. That's a pretty serious problem.

In D104500#2866103 <https://reviews.llvm.org/D104500#2866103>, @mizvekov wrote:

> Though if I may suggest, if we ever hope to sunset C++98, then to stop providing these C++11 extensions would be a good first step...

Yes, I agree those extensions are terrible. However, libc++ has supported C++11 library features with an approximative C++03 language mode ever since it was created. Removing support for something as fundamental as `std::unique_ptr` in C++03 mode is likely going to break a huge number of things, so we can't really do that. If there is a desire to sunset C++03, I could get behind that, but it would be an effort on its own and I don't think reducing what C++11 features we implement in C++03 mode would be part of that.

In the summary, you say:

> Note that we also remove implicit moves from C++98 as an extension altogether, since the expanded first overload resolution from P1825 <https://reviews.llvm.org/P1825> can cause some meaning changes in C++98. For example it can change which copy constructor is picked when both const and non-const ones are available.

So basically, you decided to downright remove the extension because it caused some code to change meaning? However, in doing so, all the code that was previously moving implicitly will now perform a copy instead (unless the copy constructor is deleted, in which case the code breaks, as in libc++). That's a pretty big behavior change. Is that accurate, or am I misunderstanding something?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104500