[ 2016-11-12, Issaquah ]

Sat PM: Status: NAD

It was said in 2010: "We need a more clearly draughted issue with an addressable set of concerns, ideally with a paper proposing a resolution, but for a future revision of the standard."

[ Moved to NAD Future at 2010-11 Batavia ]

[ 2010 Rapperswil: ]

This issue is quite vague, so it is difficult to know if and when it has been resolved. John Lakos wrote a paper covering this area a while back, and there is a real interest in providing some sort of clean-up in the future. We need a more clearly draughted issues with an addressable set of concerns, ideally with a paper proposing a resolution, but for a future revision of the standard. Move to Tentatively NAD Future.

[ 2009 Santa Cruz: ]

Move to "Open". Dave is right that this is a big issue. Paper D2987 ("Defining Move Special Member Functions", Bjarne Stroustrup and Lawrence Crowl) touches on this but does not solve it. This issue is discussed in Elements of Programming.

Issue: The CopyConstructible requirements are wishy-washy. It requires that the copy is "equivalent" to the original, but "equivalent" is never defined.

I believe this to be an example of a more general lack of rigor around copy and assignment, although I haven't done the research to dig up all the instances.

It's a problem because if you don't know what CopyConstructible means, you also don't know what it means to copy a pair of CopyConstructible types. It doesn't prevent us from writing code, but it is a hole in our ability to understand the meaning of copy.

Furthermore, I'm pretty sure that vector's copy constructor doesn't require the elements to be EqualityComparable, so that table is actually referring to some ill-defined notion of equivalence when it uses ==.