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.

### 1173. "Equivalence" wishy-washiness

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: