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

1283. MoveConstructible and MoveAssignable need clarification of moved-from state

Section: 16.4.4.2 [utility.arg.requirements] Status: Resolved Submitter: Howard Hinnant Opened: 2009-12-12 Last modified: 2016-01-28

Priority: Not Prioritized

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

View all issues with Resolved status.

Discussion:

Addresses UK 150

There is on going confusion over what one can and can not do with a moved-from object (e.g. UK 150, 910(i)). This issue attempts to clarify that moved-from objects are valid objects with an unknown state.

[ 2010-01-22 Wording tweaked by Beman. ]

[ 2010-01-22 Moved to Tentatively Ready after 5 positive votes on c++std-lib. ]

[ 2010-01-23 Alisdair opens: ]

I'm afraid I must register an objection.

My primary objection is that I have always been opposed to this kind of a resolution as over-constraining. My preferred example is a call implementing the pImpl idiom via unique_ptr. Once the pImpl has been moved from, it is no longer safe to call the vast majority of the object's methods, yet I see no reason to make such a type unusable in the standard library. I would prefer a resolution along the lines suggested in the UK comment, which only requires that the object can be safely destroyed, and serve as the target of an assignment operator (if supported.)

However, I will not hold the issue up if I am a lone dissenting voice on this (yes, that is a call to hear more support, or I will drop that objection in Pittsburgh)

With the proposed wording, I'm not clear what the term 'valid object' means. In my example above, is a pImpl holding a null pointer 'valid'? What about a float holding a signalling NaN? What determines if an object is valid? Without a definition of a valid/invalid object, I don't think this wording adds anything, and this is an objection that I do want resolved.

[ 2010-01-24 Alisdair removes his objection. ]

[ 2010-01-24 Moved to Tentatively Ready after 5 positive votes on c++std-lib. ]

[ 2010-02-10 Reopened. The wording here has been merged into 1309(i). ]

[ 2010-02-10 Moved to Tentatively NAD EditorialResolved after 5 postive votes on c++std-lib. Rationale added below. ]

Rationale:

This issue is now addressed by 1309(i).

Proposed resolution:

Change the follwing tables in 16.4.4.2 [utility.arg.requirements] as shown:

Table 33 — MoveConstructible requirements [moveconstructible]
Expression Post-condition
T t(rv) t is equivalent to the value of rv before the construction.
[Note: There is no requirement on the value of rv after the construction. rv remains a valid object. Its state is unspecified. — end note]
Table 35 — MoveAssignable requirements [moveassignable]
Expression Return type Return value Post-condition
t = rv T& t t is equivalent to the value of rv before the assigment.
[Note: There is no requirement on the value of rv after the assignment. rv remains a valid object. Its state is unspecified. — end note]