Section: 16 [library] Status: NAD Submitter: David Abrahams Opened: 2009-07-14 Last modified: 2016-11-21
Priority: 3
View other active issues in [library].
View all other issues in [library].
View all issues with NAD status.
Discussion:
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 ==.
[ 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.
[ 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.
[ Moved to NAD Future at 2010-11 Batavia ]
[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."
Proposed resolution: