On Sep 7, 2009, at 4:44 PM, Peter Dimov wrote:
My hope has been to make x = move(x) undefined behavior.
I find this a bit hard to justify.
Rationale: The move assignment operator should be fast enough that an extra if- test may adversely impact performance (above the noise level).
The problem with making it UB is that y = move(x) now needs to be guarded with if( &x != &y ) everywhere in client code. Sometimes the user will know that x is not y, but is this really the case most of the time?
It has been part of the design for the past 7 years. From N1377 (2002-09-10):
Move semantics will automatically come into play when given rvalue arguments. This is perfectly safe because moving resources from an rvalue can not be noticed by the rest of the program (<em>nobody else has a reference to the rvalue in order to detect a difference</ em>).
Here it is again in N1690 (2004-09-07):
When the argument is an rvalue, the author of the class knows that he has a unique reference to the argument.
The overload taking an rvalue can modify the argument in whatever invariant preserving way it pleases and be guaranteed that the rest of the program will not notice!
I'm currently thinking that we need a Chapter 17 statement along the lines of: The C++ standard library may assume that an rvalue reference represents a unique reference to the bound object. This statement would have been more difficult to write the standardeze for prior to N2831 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2831.html ). This would make [container.requirements.general]/12 redundant, and that paragraph could thus be removed. This would also mean that for every class type defined by the standard library with a move assignment operator: C& C::operator=(C&& rhs); This signature may assume that rhs represents the only reference to the object bound to rhs. After all if the library can't assume (for example) that in vector::push_back(T&& t); t is a unique reference to some object, then it can't very well destructively modify that object while appending it to the vector. -Howard