After taking C++98 implicit moves out in D104500,
we put it back in, but now in a new form which preserves
compatibility with pure C++98 programs, while at the same time
giving almost all the goodies from P1825.
- We use the exact same rules as C++20 with regards to which id-expressions are move eligible. The previous incarnation would only benefit from the proper subset which is copy ellidable. This means we can implicit move, in addition:
- Parameters.
- RValue references.
- Exception variables.
- Variables with higher-than-natural required alignment.
- Objects with different type from the function return type.
- We preserve the two-overload resolution, with one small tweak to the first one: If we either pick a (possibly converting) constructor which does not take an rvalue reference, or a user conversion operator which is not ref-qualified, we abort into the second overload resolution.
This gives C++98 almost all the implicit move patterns which we had created test
cases for, while at the same time preserving the meaning of these
three patterns, which are found in pure C++98 programs:
- Classes with both const and non-const copy constructors, but no move constructors, continue to have their non-const copy constructor selected.
- We continue to reject as ambiguous the following pattern:
struct A { A(B &); };
struct B { operator A(); };
A foo(B x) { return x; }- We continue to pick the copy constructor in the following pattern:
class AutoPtrRef { };
struct AutoPtr {
AutoPtr(AutoPtr &);
AutoPtr();
AutoPtr(AutoPtrRef);
operator AutoPtrRef();
};
AutoPtr test_auto_ptr() {
AutoPtr p;
return p;
}Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
It sure would be nice to factor something out into a function here so that we didn't need a goto. Either replace the goto with
or else pull the Step stuff out into a static bool PermitImplicitMoveSequence(...) or whatever an appropriate name might be:
if ((Res == OR_Success || Res == OR_Deleted) && PermitImplicitMoveSequence(Seq)) { // Promote "AsRvalue" to the heap, etc etc