Re: [boost] [contract] move operations and class invariants

Subject: Re: [boost] [contract] move operations and class invariants
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-11-30 03:40:20

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().