Boost :

hinnant_at_[hidden]

---
In general, std::types, when dealing with rvalue references which are  
overloaded with lvalue references, the std::code is allowed to assume  
that it is dealing with an actual temporary, and not a moved-from  
lvalue.  Reference:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1858.html#23.1%20-%20Container%20requirements
paragraph 13:
> -13- Those container member functions with rvalue-reference  
> parameters may assume that the reference truly refers to an rvalue,  
> and specifically is not a reference into the same container.
Example:
template > class vector {
...
    iterator insert(iterator position, const T& x);
    iterator insert(iterator position, T&& x);
...
};
Inside the insert overload taking a T&&, the code is allowed to assume  
that x has bound to a temporary.  This means that the code does not  
have to check for the self-referencing case, and is thus faster.  If a  
client moves an lvalue to the insert signature, the onus is on the  
client to make sure that all existing references to that lvalue  
promise not to notice (or care) that the lvalue has been moved from.
void foo()
{
     std::vector<A> v(10);
     v.insert(v.end(), std::move(v.front()));
}
The above is a run time error similar to:
void foo()
{
     std::vector<A> v(10);
     v.insert(v.end(), v.begin(), v.begin()+1);
}
(the latter is currently forbidden by 23.1.1, p4)
---
Now let's look at the other side:
void foo()
{
     A a;
     std::vector<A> v;
     v.insert(v.end(), std::move(a));
     // Here "a" is required to be in a valid state, but the value of  
"a" is unknown
}
The definition of "valid" is up to the author of A.  At a minimum,  
generic code will need to destruct and/or assign "a" a new value.   
However the author of A is free to define as part of the class  
invariant:
     After an A is moved from, you can't call A::bar()
I don't think that is a very good design myself.  But I also don't  
think the standard should prohibit it.
For std::types I do not want to see any such restrictions on moved- 
from values.  For example if a vector gets moved from, I expect it to  
still be fully functional, just with an unknown state (but you can  
test the state with the existing interface, e.g. size(), capacity(),  
empty(), etc.), and set the state however you like.
With perhaps a few exceptions, I do not want to see the value of a  
moved-from std::type specified.  For example:
std::string s1("123");
std::string s2(std::move(s1));
// value of s1 not reliable here.  "123" and "" are two good guesses
---
Originally I preferred vector move assignment as just swap().  However  
I've recently become convinced that this is not the best definition.   
I now prefer the semantics of clear(); swap();.  This means that move  
assignment is O(N) instead of O(1).  Ok Ion, take a deep breath and  
stay with me for just a minute longer. :-)
The semantics of ~thread() is going to be cancel(); detach();.  That  
is, if thread A is holding a std::thread referencing thread B, and  
thread C cancels thread A, as thread A's stack unwinds, it will  
execute b.~thread() which cancels B, but does not wait around for B to  
respond to the cancel.  Thus canceling A will not hang waiting on B to  
finish up.
Now consider vector<thread>:
vector<thread> v1;
...
vector<thread> v2;
...
v1 = std::move(v2);
After the move assign, I think it best that whatever threads v1  
happened to previously refer to, are now busy canceling themselves,  
instead of continuing to run under v2's ownership.  If you want the  
latter, you've got swap.
Cost analysis:  It isn't nearly as bad as it sounds.  Promise!!! :-)
First, for vector<type with trivial destructor>, clear() is O(1) in  
practice (or it should be).  And clear() does not dump capacity, so  
the capacity gets reused via the swap.  So we only have to worry about  
vector<type with non-trivial destructor>.
Consider vector<vector<thread>>::insert.  And we're going to insert a  
new vector<thread> at begin().  The case where there is insufficient  
capacity only uses move construction, and not move assignment.  So  
assume there is sufficient capacity.
In this case we first move construct *--end() into *end().  This move  
construction leaves a zero capacity vector<thread> at *--end() (though  
that value should not be guaranteed, there is really little else  
vector can do for move construction).
The next step is:
    *(end()-1) = std::move(*(end()-2));
Now we already said that *(end()-1) is a zero capacity vector<thread>  
prior to this move assignment.  Therefore when the move assignment  
clears it, that clear is a no-op.  Then the states are swapped, making  
*(end()-2) a zero capacity vector (again, that state should not be  
guaranteed, but it is practical).
Repeat:
    *(end()-2) = std::move(*(end()-3));
Again we are move assigning into a zero-capacity vector, so  
clear();swap(); and just swap(); are virtually identical sequences of  
instructions.  This repeats all the way down to:
   *(begin()+1) = std::move(*begin());
leaving *begin() as a zero capacity vector<thread>.  Then the outside  
vector<thread> is moved assigned into *begin().  The outside temporary  
vector<thread> is then a zero capacity vector and presumably destructs.
Summary:  For vector<vector<thread>>::insert, defining vector move  
assignment as clear()+swap() instead of just swap() has a nearly  
identical cost.  There are no extra destructions.
I've gone through the same analysis with vector::erase, and all  
sequence modifying algorithms in <algorithm> which make use of move  
semantics.  During all of these generic algorithms, move assignment is  
always assigning to a source that has already been moved from.  Thus  
"clearing" the source is a no-op.  And I consider the  
container::insert/erase and <algorithm>'s as one of the biggest  
consumers of move semantics, and even more importantly, as typical use  
cases of move semantics.
In general, if you are move assigning *to* something.  You've probably  
already move assigned or move constructed *from* it.  That being said,  
if you haven't already moved from the target, and the target is a  
std::container or other std::type which owns objects, I think a  
"clear" is prudent so that move assignment has the same semantics as  
copy assignment.
Getting back to shared_ptr move assignment, I would like to see the  
target's reference count decremented if it is not already at 0 prior  
to the move assignment (just as in copy assignment - this is the  
"clear" part of the algorithm).  I would also like to not see any  
*new* constraints placed on the source as a result of being moved  
from.  And finally I do not see the need to specify the value of the  
source after the move.  I would like vendors to have the freedom to  
implement shared_ptr move assignment exactly as they do shared_ptr  
copy assignment.  If atomic operations can be avoided (for example) by  
assuming that the source is a temporary (under move assignment) then  
so much the better.
-Howard