[cfe-dev] deprecating copy construction and assignment

[Howard Hinnant]

On Mar 29, 2012, at 5:42 PM, Sean Silva wrote:

> Could someone explain why the second one is move-constructible and move-assignable while the first one is not?
> 
> How does explicitly defaulting the move-constructor and move-assignment cause A to *not* be move-constructible nor move-assignable, while omitting them makes A be move-constructible and move-assignable?

Note that application of:

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1402

changes everything.  But prior to application of this bug fix to C++11:

> struct member
> {
>    member();
>    member(const member&);
>    member& operator=(const member&);
>    ~member();
> };
> 
> struct A
> {
>    member m_;
> 
>    A() = default;
>    A(const A&) = default;
>    A& operator=(const A&) = default;
>    A(A&&) = default;
>    A& operator=(A&&) = default;
>    ~A() = default;
> };

A defaulted move constructor (assignment) is implicitly deleted if a base class or non-static data member does not have a move constructor (assignment), or if it has a non-trivial copy constructor (assignment).

After the application of cwg#1402, the above defaulted move constructor (assignment) will not be deleted, but will instead call the copy constructor (assignment) of 'member'.  Thus A will be move constructible and move assignable.


> A is neither move constructible nor move assignable.  The following is probably what was intended:
> 
> struct A
> {
>    member m_;
> 
>    A() = default;
>    A(const A&) = default;
>    A& operator=(const A&) = default;
>    ~A() = default;
> };

In this example A does not have a move constructor nor move assignment operator.  Yet it is move constructible (assignable) because one can construct (assign) it using an rvalue A as the source.  The copy constructor (assignment) is used for this operation.  cwg#1402 will not impact this example.

Howard