Addresses UK 150

The description of the effect of operator= in the MoveAssignable concept, given in paragraph 7 is:

result_type  T::operator=(T&&  rv);  // inherited from HasAssign<T, T&&>

Postconditions: the constructed T object is equivalent to the value of rv before the assignment. [Note: there is no requirement on the value of rv after the assignment. --end note]

The sentence contains a typo (what is the "constructed T object"?) probably due to a cut&paste from MoveConstructible. Moreover, the discussion of LWG issue 675 shows that the postcondition is too generic and might not reflect the user expectations. An implementation of the move assignment that just calls swap() would always fulfill the postcondition as stated, but might have surprising side-effects in case the source rvalue refers to an object that is not going to be immediately destroyed. See LWG issue 900 for another example. Due to the sometimes intangible nature of the "user expectation", it seems difficult to have precise normative wording that could cover all cases without introducing unnecessary restrictions. However a non-normative clarification could be a very helpful warning sign that swapping is not always the correct thing to do.