Proposed resolution:

This wording is relative to N4606.

1. In [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]

[ 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 [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 [container.requirements.general] noted in the issue discussion.

[ 2016-09-09 Issues Resolution Telecon ]

Move to Tentatively Ready

[ 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-08 Chicago ]

Tuesday AM: Move to Tentatively Ready

Previous resolution [SUPERSEDED]:

In [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-01, Howard provided wording ]

[ 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

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.

[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 [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 [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:

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

• [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.

• [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 [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 [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.