The addition of move semantics to the language means that many library APIs leave an object in a safely-destructible state, where no other operations can safely be performed unless it is assigned a new value. Library presentation would be simplified and made more precise if we introduce a term for this state. By analogy with singular iterators suggest the term ‘singular object’ or ‘the object is in a singular state’.
Define ‘singular state’ such that an object with a singular state can only be assigned to or safely destroyed. Assiging a new value typically removes the singular state. Note that objects with a singular state may not be safely copied, so you cannot put an object into a singular state by copying another object in a singular state.
Use this new term in the postcondition of all library APIs that move from an rvalue reference.
It might also be used to simplify the definition of singular iterator to an iterator value with a singular state.
Objects that have been moved from are generally OK
In most cases a moved-from object is equivalent to a default-constructed object of the same type. It is not up to the library to declare such an object as “singular”, although I am happy with the definition of the term in case a moved-from object is no longer usable.
I agree with them being OK
Early on I thought moved-from objects should have some very limited set of operations permitted on them. However in practice it is indeed easiest (I think) to say they should have a valid, but undefined, status.
There seems to be 3 states objects can end up after being moved from I’ve seen in practice.
1) Default Constructed
2) Same state as before (because move constructing = copy constructing)
3) The state of the object being assigned to (because move assignment = swap)
Although you have to be careful with (3), it can’t just be applied blindly.
Although, it would be very nice (I think) if compilers / debugging libraries were permitted to flag any operation applied to a moved-from object other than destructing it or assigning to it, because such an operation is almost certainly a mistake.
Moved-from objects should be copyable
We discussed on the list, and it was pointed out that it is reasonable to copy moved-from objects, eg copying a container after a call to remove.
My preference is that moved-from objects should have unspecified value (this is what basic_string currently says) – so you can copy, move, assign etc, but cannot rely on them having any particular value.
But it makes sense for some components to give extra guarantees – eg if you move from a shared_ptr, it is important that it no longer maintains ownership.
deleted assignment
If assignment is deleted then no instances of the class can be singular.
Roger Orr
Singular objects
The minimum operation supported on a singular object is to safely destruct it.
Individual classes may provide more guarantees, for example that a singular instance is equivalent to a default constructed object.
However, generic (template) code cannot assume more than the minimum.
Roger Orr