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

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

Rationale:

This issue is now addressed by 1309.

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]