Proposed resolution:

This wording is relative to N4861.

1. Add a new paragraph at the end of [lib.types.movedfrom]:

   -1- Objects of types defined in the C++ standard library may be moved from ([clss.copy.ctor]). Move operations may be explicitly specified or implicitly generated. Unless otherwise specified, such moved-from objects shall be placed in a valid but unspecified state.

   -?- An object of a type defined in the C++ standard library may be move-assigned ([class.copy.assign]) to itself. Unless otherwise specified, such an assignment places the object in a valid but unspecified state.

2. Edit [res.on.arguments]/1, bullet 3, as indicated:

   -1- Each of the following applies to all arguments to functions defined in the C++ standard library, unless explicitly stated otherwise.

   1. (1.1) — […]

   2. (1.2) — […]

   3. (1.3) — If a function argument binds to an rvalue reference parameter, the implementation may assume that this parameter is a unique reference to this argument, except that the argument passed to a move-assignment operator may be a reference to *this ([lib.types.movedfrom]). [Note: If the type of a parameter is a generic parameter of the form T&& and an lvalue of type A is bound, the argument binds to an lvalue reference ([temp.deduct.call]) and thus is not covered by the previous sentence. forwarding reference ([temp.deduct.call]) that is deduced to an lvalue reference type, then the argument is not bound to an rvalue reference. — end note] [Note: If a program casts an lvalue to an xvalue while passing that lvalue to a library function (e.g. by calling the function with the argument std::move(x)), the program is effectively asking that function to treat that lvalue as a temporary. The implementation is free to optimize away aliasing checks which might be needed if the argument was an lvalue. — end note]

3. Edit Table 73 "Container requirements" in [container.requirements.general] as indicated:

   Table 73 — Container requirements

   Expression	Return type	Operational semantics	Assertion/note pre-/post-condition	Complexity
   …
   a = rv	T&	All existing elements of a are either move assigned to or destroyed	Postconditions: If a and rv do not refer to the same object, a is equal to the value that rv had before this assignment.	linear
   …

4. Edit Table 76 "Allocator-aware container requirements" in [container.requirements.general] as indicated:

   Table 86 — Allocator-aware container requirements

   Expression	Return type	Assertion/note pre-/post-condition	Complexity
   …
   a = rv	T&	Preconditions: If allocator_traits<allocator_type> ::propagate_on_container_move_assignment::value is false, T is Cpp17MoveInsertable into X and Cpp17MoveAssignable. Effects: All existing elements of a are either move assigned to or destroyed. Postconditions: If a and rv do not refer to the same object, a is equal to the value that rv had before this assignment.	linear
   …

[ 2020-11-09 Approved In November virtual meeting. Status changed: Ready → WP. ]

[ 2020-07-17; issue processing telecon ]

LWG reviewed the latest proposed resolution. Unanimous consent to move to Ready.

[ 2020-06-06 Tim restores and updates P/R following 2020-05-29 telecon discussion ]

The standard doesn't define phrases like "default constructible" used in the previous P/R. Moreover, the library provides a variety of wrapper types, and whether these types meet the semantic requirements of Cpp17Meowable (and maybe even syntactic, depending on how "copy constructible" is interpreted) depends on the property of their underlying wrapped types, which might not even be an object type (e.g., tuple or pair of references). This is a large can of worms (see LWG 2146) that we don't want to get into.

There is a suggestion in the telecon to blanket-exempt move-assignment operators from the [res.on.arguments] 1.3 requirement. The revised wording below does not do so, as that would carve out not just self-move-assignment but also other aliasing scenarios in which the target object owns the source object. Whether such scenarios should be permitted is outside the scope of this issue, though notably assignable_from ([concept.assignable]) contains a note alluding to these cases and suggesting that they should be considered to be outside the domain of = entirely.

[ 2018-08-23 Batavia Issues processing ]

Howard and Tim to discuss a revised P/R.

Previous resolution [SUPERSEDED]:

This wording is relative to N4762.

1. Add a new subsection to [conforming] after [member.functions]:

   Special members [conforming.special]

   Class types defined by the C++ standard library and specified to be default constructible, move constructible, copy constructible, move assignable, copy assignable, or destructible, shall meet the associated requirements Cpp17DefaultConstructible, Cpp17MoveConstructible, Cpp17CopyConstructible, Cpp17MoveAssignable, Cpp17CopyAssignable, and Cpp17Destructible, respectively ([utility.arg.requirements]).

[ 2018-08-16, Howard comments and provides updated wording ]

I agreed to provide proposed wording for LWG 2839 that was reworded to use MoveAssignable. The advantage of this is that MoveAssignable specifies the self-assignment case, thus we do not need to repeat ourselves.

[ 2018-1-26 issues processing telecon ]

Status to 'Open'; Howard to reword using 'MoveAssignable'.

Previous resolution [SUPERSEDED]:

This wording is relative to N4618.

1. Add a new paragraph at the end of [lib.types.movedfrom]:

   -1- Objects of types defined in the C++ standard library may be moved from (12.8). Move operations may be explicitly specified or implicitly generated. Unless otherwise specified, such moved-from objects shall be placed in a valid but unspecified state.

   -?- An object of a type defined in the C++ standard library may be move-assigned ([class.copy.assign]) to itself. Such an assignment places the object in a valid but unspecified state unless otherwise specified.

2. Add a note at the end of [res.on.arguments]/1, bullet 3, as indicated:

   -1- Each of the following applies to all arguments to functions defined in the C++ standard library, unless explicitly stated otherwise.

   1. (1.1) — […]

   2. (1.2) — […]

   3. (1.3) — If a function argument binds to an rvalue reference parameter, the implementation may assume that this parameter is a unique reference to this argument. [Note: If the parameter is a generic parameter of the form T&& and an lvalue of type A is bound, the argument binds to an lvalue reference (14.8.2.1) and thus is not covered by the previous sentence. — end note] [Note: If a program casts an lvalue to an xvalue while passing that lvalue to a library function (e.g. by calling the function with the argument std::move(x)), the program is effectively asking that function to treat that lvalue as a temporary. The implementation is free to optimize away aliasing checks which might be needed if the argument was an lvalue. — end note] [Note: This does not apply to the argument passed to a move assignment operator ([lib.types.movedfrom]). — end note]

3. Edit Table 83 "Container requirements" in [container.requirements.general] as indicated:

   Table 83 — Container requirements

   Expression	Return type	Operational semantics	Assertion/note pre-/post-condition	Complexity
   …
   a = rv	T&	All existing elements of a are either move assigned to or destroyed	post: If a and rv do not refer to the same object, a shall be equal to the value that rv had before this assignment	linear
   …

4. Edit Table 86 "Allocator-aware container requirements" in [container.requirements.general] as indicated:

   Table 86 — Allocator-aware container requirements

   Expression	Return type	Assertion/note pre-/post-condition	Complexity
   …
   a = rv	T&	Requires: If allocator_traits<allocator_type >::propagate_on_container_move_assignment::value is false, T is MoveInsertable into X and MoveAssignable. All existing elements of a are either move assigned to or destroyed. post: If a and rv do not refer to the same object, a shall be equal to the value that rv had before this assignment	linear
   …

[ 2017-01-27 Telecon ]

Priority 2

LWG 2468's resolution added to MoveAssignable the requirement to tolerate self-move-assignment, but that does nothing for library types that aren't explicitly specified to meet MoveAssignable other than make those types not meet MoveAssignable any longer.

To realize the intent here, we need to carve out an exception to [res.on.arguments]'s restriction for move assignment operators and specify that self-move-assignment results in valid but unspecified state unless otherwise specified. The proposed wording below adds that to [lib.types.movedfrom] since it seems to fit well with the theme of the current paragraph in that section.

In addition, to address the issue with [container.requirements.general] noted in LWG 2468's discussion, the requirement tables in that subclause will need to be edited in a way similar to LWG 2468.