What does the standard say about move-assignment to self in the case of MoveAssignable?

user_8157187 0
Viewed 204

Here's C++17's current description of MoveAssignable:

t = rv;

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 ]

What does "rv must still meet the requirements of the library component that is using it" refer to?

What if t & rv refer to the same object? What can/should a type with MoveAssignable do in this case?

Does the description mean:

  1. the library won't call move assignment with self at all, so the type can do whatever it wants in this case (even crash)

  2. or the type should handle this case somehow (no crashing allowed), but its result doesn't matter

  3. or something else?

Note: there are similar questions here at SO, but there are conflicting/old (C++14 has different rules) answers, comments, so I'd like to clarify this.

c++17 language-lawyer c++
1 Answers

What does "rv must still meet the requirements of the library component that is using it" refer to?

This is a roundabout way of saying that even though rv's state is unspecified, it must be a valid state. For instance, a type which records an "I'm gone!" state and throws exceptions for subsequent re-assignments is not allowed, if assignment is one of the required-to-be-supported operations.

What if t & rv refer to the same object?

You already quoted the answer to that: "rv's state is unspecified." This is independent of whether t refers to the same object.

Does the description mean:

  1. or the type should handle this case somehow (no crashing allowed), but its result doesn't matter

Yes, this, pretty much.

Admin1
Related