[cfe-dev] deprecating copy construction and assignment

[Howard Hinnant]

On Mar 29, 2012, at 11:28 AM, Jeffrey Yasskin wrote:

> On Thu, Mar 29, 2012 at 7:31 AM, Jonathan Sauer <jonathan.sauer at gmx.de> wrote:
>> Hello,
>> 
>>> One needs to be more careful with defaulting the move members.  It is easy to default them and have them get implicitly deleted:
>>> 
>>> 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 is neither move constructible nor move assignable.  The following is probably what was intended:
>> 
>> I suggest enhancing the error message with an explanation: "A is not move assignable because member 'm_'
>> has an {explicitly|implicitly} deleted move assignment operator." Or even "... has a move assignment
>> operator that was implicitly deleted by the explicit copy assignment operator".
> 
> I prefer the last one. Users (including me) get confused when we tell
> them that something was deleted but not why/how to avoid deleting it.

I just became aware of cwg 1402 which is in ready status:

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

This change will no longer make A's move members deleted.  Instead A will get move members that copy the data member.

This is a very good change as the current rules are extremely error prone.  The library section of the standard itself was bitten by these rules in the move constructor of both tuple and pair (which are explicitly defaulted).

As this issue is both non-controversial, and already in ready status, I think it would be a good idea to go ahead and implement it.  That will likely be easier than designing warnings for the implicit deletion of explicitly defaulted move members.

Howard