Proposed resolution:

Resolved by n3215.

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

[ 2009-07 Frankfurt: ]

Move to Ready with original proposed resolution.

Howard: Original proposed resolution restored.

[ 2009-07 Frankfurt: ]

Need to look at again without concepts.

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

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

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