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

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov added a comment.

In D104500#2867404 <https://reviews.llvm.org/D104500#2867404>, @ldionne wrote:

> 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.

That was not clear from the clang side, we had those extensions as non officially supported.
Now since another project under the same umbrella depends on it, it makes sense to continue supporting this, at least until we agree on something else.

> 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?

Well, considering from my perspective, which had those extensions as not officially supported and "best effort" only, it would make sense not to provide an extension which can break pure C++98 programs.
The options where:

1. DR P1825 <https://reviews.llvm.org/P1825> down to C++11 as the comittee decided, but get almost no benefit from implementation complexity because we would still have to keep most of the code around, but this time only for C++98 (which is not even supposed to have it).
2. Leave C++98 without implicit moves. This gives following benefits:
  - Drop huge amount of code, almost no new code.
  - Pure C++98 programs don't get broken.
  - Less work, I can spend more time doing other things.
3. DR P1825 <https://reviews.llvm.org/P1825> down to C++98. This gives almost all the benefits from the option above, except that has risk of breaking valid C++98 code.
4. Invent yet another new implicit move rule.

We tried 2, and failed here.
Number 3 would be cool if we could get away with it, but I don't know if we should take the chances.
So I present my take on option 4: https://reviews.llvm.org/D105756


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104500