[cfe-dev] deprecating copy construction and assignment

[Richard Smith]

On Thu, Mar 29, 2012 at 12:06 PM, Howard Hinnant <hhinnant at apple.com> wrote:

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

I agree. I happen to be currently working on the implicit deletion of
special member functions anyway, so I'll make this change.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120329/f442b359/attachment.html>