This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.

### 822. Object with explicit copy constructor no longer `CopyConstructible`

Section: 16.4.4.2 [utility.arg.requirements] Status: NAD Submitter: James Kanze Opened: 2008-04-01 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [utility.arg.requirements].

View all issues with NAD status.

Discussion:

I just noticed that the following program is legal in C++03, but is forbidden in the current draft:

>     #include <vector>
>     #include <iostream>

>     class Toto
>     {
>     public:
>         Toto() {}
>         explicit Toto( Toto const& ) {}
>     } ;

>     int
>     main()
>     {
>         std::vector< Toto > v( 10 ) ;
>         return 0 ;
>     }

Is this change intentional? (And if so, what is the justification? I wouldn't call such code good, but I don't see any reason to break it unless we get something else in return.)

[ San Francisco: ]

> The subgroup that looked at this felt this was a good change, but it may already be handled by incoming concepts (we're not sure).

[ Post Summit: ]

> Alisdair: Proposed resolution kinda funky as these tables no longer exist. Move from direct init to copy init. Clarify with Doug, recommends NAD.

> Walter: Suggest NAD via introduction of concepts.

> Recommend close as NAD.

[ 2009-07 Frankfurt: ]

> Need to look at again without concepts.

[ 2009-07 Frankfurt: ]

> Move to Ready with original proposed resolution.

> [Howard: Original proposed resolution restored.]

[ 2010-11 Batavia: ]

This issue was re-reviewed in relation to [another issue, number to follow], and the verdict was reversed. Explicit copy and move constructors are rare beasts, and the ripple effect of this fix was far more difficult to contain than simply saying such types do not satisfy the `MoveConstructible` and `CopyConstructible` requirements.

> In 16.4.4.2 [utility.arg.requirements] change Table 33: `MoveConstructible` requirements [moveconstructible]:

> > expression | post-condition
> > --- | ---
> > `T t(rv) = rv` | `t` is equivalent to the value of `rv` before the construction
> > ...

> In 16.4.4.2 [utility.arg.requirements] change Table 34: `CopyConstructible` requirements [copyconstructible]:

> > expression | post-condition
> > --- | ---
> > `T t(u) = u` | the value of `u` is unchanged and is equivalent to `t`
> > ...

Proposed resolution:

Resolved by n3215.