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

### 2468. Self-move-assignment of library types

Section: 16.4.5.9 [res.on.arguments], 16.4.4.2 [utility.arg.requirements], 16.4.6.15 [lib.types.movedfrom], 24.2.2.1 [container.requirements.general] Status: C++17 Submitter: Matt Austern Opened: 2015-01-22 Last modified: 2017-07-30

Priority: 2

View all other issues in [res.on.arguments].

View all issues with C++17 status.

Discussion:

Suppose we write

>     vector<string> v{"a", "b", "c", "d"};
>     v = move(v);

What should be the state of `v` be? The standard doesn't say anything specific about self-move-assignment. There's relevant text in several parts of the standard, and it's not clear how to reconcile them.

16.4.5.9 [res.on.arguments] writes that, for all functions in the standard library, unless explicitly stated otherwise, "If a function argument binds to an rvalue reference parameter, the implementation may assume that this parameter is a unique reference to this argument." The `MoveAssignable` requirements table in 16.4.4.2 [utility.arg.requirements] writes that, given `t = rv`, `t`'s state is equivalent to `rv`'s from before the assignment and `rv`'s state is unspecified (but valid). For containers specifically, the requirements table in 24.2.2.1 [container.requirements.general] says that, given `a = rv`, `a` becomes equal to what `rv` was before the assignment (and doesn't say anything about `rv`'s state post-assignment).

Taking each of these pieces in isolation, without reference to the other two:

- 16.4.5.9 [res.on.arguments] would clearly imply that the effect of `v = move(v)` is undefined.

- 16.4.4.2 [utility.arg.requirements] would clearly imply that `v = move(v)` has defined behavior. It might be read to imply that this is a no-op, or might be read to imply that it leaves `v` in a valid but unspecified state; I'm not sure which reading is more natural.

- 24.2.2.1 [container.requirements.general] would clearly imply that `v = move(v)` is a no-op.

It's not clear from the text how to put these pieces together, because it's not clear which one takes precedence. Maybe 16.4.5.9 [res.on.arguments] wins (it imposes an implicit precondition that isn't mentioned in the `MoveAssignable` requirements, so `v = move(v)` is undefined), or maybe 24.2.2.1 [container.requirements.general] wins (it explicitly gives additional guarantees for `Container::operator=` beyond what's guaranteed for library functions in general, so `v = move(v)` is a no-op), or maybe something else.

On the existing implementations that I checked, for what it's worth, `v = move(v)` appeared to clear the vector; it didn't leave the vector unchanged and it didn't cause a crash.

Proposed wording:

Informally: change the `MoveAssignable` and Container requirements tables (and any other requirements tables that mention move assignment, if any) to make it explicit that `x = move(x)` is defined behavior and it leaves `x` in a valid but unspecified state. That's probably not what the standard says today, but it's probably what we intended and it's consistent with what we've told users and with what implementations actually do.

[2015-10, Kona Saturday afternoon]

JW: So far, the library forbids self-assignment since it assumes that anything bound to an rvalue reference has no aliases. But self-assignment can happen in real code, and it can be implemented. So I want to add an exception to the Standard that this should be allowed and leave the object in a valid-but-unspecified state.

STL: When this is resolved, I want to see a) VBU for library types after self-move, but also b) requirements on user types for self-moves. E.g. should algorithms be required to avoid self-assignments (since a user-defined type might blow up)? HH: In other words, should we require that you can assign from moved-from values.

WEB: What can one generally do with moved-from values?

VV: Call any member function that has no preconditions.

JW: That's certainly the library requirement, and it's also good guidance for user types.

JW: I'm writing wording. I care about this.

Move to Open; Jonathan to provide wording

[2016-08-01, Howard provided wording]

[2016-08 Chicago]

Tuesday AM: Move to Tentatively Ready

Previous resolution [SUPERSEDED]:

> In 16.4.4.3 [swappable.requirements], modify Table 23 — `MoveAssignable` requirements [moveassignable]:

> > Table 23 — `MoveAssignable` requirements [moveassignable]
> > Expression | Return type | Return value | Post-condition
> > --- | --- | --- | ---
> > `t = rv` | `T&` | `t` | If `addressof(t) != addressof(rv)`, `t` is equivalent to the value of `rv` before the assignment
> > `rv`'s state is unspecified. [Note: `rv` must still meet the requirements of the library component that is using it, whether or not `addressof(t) == addressof(rv)`. The operations listed in those requirements must work as specified whether `rv` has been moved from or not. — end note]

[2016-08-07, Daniel reopens]

With the acceptance of LWG 2598, the proposed wording is invalid code, because it attempts to call `std::addressof` with an rvalue argument. It should be pointed out that the new restriction caused by 2598 doesn't affect real code, because any identity test within a move assignment operator (or any comparable function) would act on the current function argument, which is an lvalue in the context of the function body. The existing wording form of the issue could still be kept, if a helper variable would be introduced such as:

> Let `refrv` denote a reference initialized as if by `const T& refrv = rv;`. Then if `addressof(t) != addressof(refrv)`, `t` is equivalent to the value of `rv` before the assignment

But it seems to me that the same effect could be much easier realized by replacing the code form by a non-code English phrase that realizes the same effect.

[2016-09-09 Issues Resolution Telecon]

Move to Tentatively Ready

[2016-10-05, Tim Song comments]

The current P/R of LWG 2468 simply adds to `MoveAssignable` the requirement to tolerate self-move-assignment, but that doesn't actually do much about self-move-assignment of library types. Very few types in the library are explicitly required to satisfy `MoveAssignable`, so as written the restriction in 16.4.5.9 [res.on.arguments] would seem to still apply for any type that's not explicitly required to be `CopyAssignable` or `MoveAssignable`.

The current P/R also doesn't address the issue with 24.2.2.1 [container.requirements.general] noted in the issue discussion.

Proposed resolution:

This wording is relative to N4606.

1. In 16.4.4.3 [swappable.requirements], modify Table 23 — `MoveAssignable` requirements [moveassignable]:

   > Table 23 — `MoveAssignable` requirements [moveassignable]
   > Expression | Return type | Return value | Post-condition
   > --- | --- | --- | ---
   > `t = rv` | `T&` | `t` | If `t` and `rv` do not refer to the same object, `t` is equivalent to the value of `rv` before the assignment
   > `rv`'s state is unspecified. [Note: `rv` must still meet the requirements of the library component that is using it, whether or not `t` and `rv` refer to the same object. The operations listed in those requirements must work as specified whether `rv` has been moved from or not. — end note]