[cfe-dev] Move constructor forces copy assignment to be implicitly defaulted?

[Howard Hinnant]

On May 25, 2012, at 4:44 AM, Suman Kar wrote:

> My reading of the relevant section of the standard (I only have N3126
> handy, so I may be mistaken): §12.8/20:
> 
>      If the class definition does not explicitly declare a
>      copy assignment operator and there is no user-declared
>      move assignment operator, a copy assignment operator
>      is implicitly declared as defaulted (8.4).
> 
> tells me that an implicitly *defaulted* copy assignment operator
> should've been generated and used instead.

This paragraph now reads:

> If the class definition does not explicitly declare a
> copy assignment operator, one is declared implicitly.
> If the class definition declares a move constructor or
> move assignment operator, the implicitly declared copy
> assignment operator is defined as deleted; otherwise, it
> is defined as defaulted (8.4).

So the declaration of movable(movable &&) deletes the copy assignment operator.

This paragraph goes on to say:

> The latter case is deprecated if the class has a user-declared
> copy constructor or a user-declared destructor.

I.e. even without the move constructor, the declared copy constructor makes the defaulted copy assignment deprecated.  It may become deleted in a future standard.

In summary, if you declare either copy member or the destructor, implicit move members are inhibited.  If you declare either move member, the copy members are implicitly deleted unless you declare them otherwise.

Howard