[PATCH] D99005: [clang] Implement P2266 Simpler implicit move

Tue Jul 6 13:35:24 PDT 2021

mizvekov added a comment.

In D99005#2860598 <https://reviews.llvm.org/D99005#2860598>, @Quuxplusone wrote:

> I have no strong/well-informed opinions here. I have an idea to offer, //if// there is precedent for it. My idea is, keep it as an error if the rvalue resolution finds nothing, but (1) fall back to an lvalue resolution //for error-recovery purposes//, and (2) suppress the error in system headers. Then, the usage in MSVC STL will keep working but only because it's in a system header. I seem to recall that there is precedent for diagnostics that are "non-downgradable error in user code, yet still suppressed in system headers." If I'm imagining things, then please do not invent such a facility purely for this feature.

That would still leave the effect of changing the deduced type of a `decltype(auto)` returning function. But I am on the same boat here in that I am not sure if you are imagining things as well :)

> My second choice is to do whatever minimalistic hack suffices to satisfy the customer (Aaron etc. in this case), but only with the understanding that we plan to eliminate that hack as soon as MSVC STL gets updated. My third choice is to revert the whole thing and then land a new version of it that always falls back to lvalue resolution, but with an on-by-default //warning// (not error) (so this would probably affect a ton of your test cases); then the user can downgrade that warning as a workaround.

Again, the change in flow where we make the expression an xvalue early and definitively before return type deduction occurs makes things more complicated.

My vote is the second choice, as I think making a workaround where we temporarily do the C++20 thing only in some contexts is far simpler, specially if we don't have to update a ton of test cases to cover it :)

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99005