On 30/11/2017 11:45, I wrote:
To put it another way, if you move-assign a vector to another vector, it is perfectly legal for the source vector to not be empty afterwards. (For example, instead of a destroy-and-swap it could be implemented as a pure swap. Or even as a copy, although that's less likely with modern STLs.) [...] (At this point language lawyers might jump on me that vector does actually provide somewhat more specific guarantees about how move-assign behaves. But the point stands for generic types.)
Donning my own language-lawyer hat for a moment: there are actually some cases where a modern STL is actually *required* to implement a move-assign like a copy-assign -- notably when containing a type that has a custom copy-constructor without a custom move-constructor and using a non-propagate_on_container_move_assignment allocator which doesn't compare equal. Perhaps this can be argued to be a niche case, but it would indeed be a case where the source vector isn't empty afterwards, thus requiring the clear().