LWG3511 Clarify global permission to move

[jwakely]

https://cplusplus.github.io/LWG/issue3511

@gonzalobg suggested that SG1 could help with providing an example for the "whole program scope" interpretation to show how it's problematic.

Maybe it makes sense to phrase the permission in similar terms to [res.on.data.races], i.e. "the argument bound to an rvalue reference parameter does not alias objects indirectly accessible via its arguments or via elements of its container arguments".

I'm not convinced it makes sense for "the library can assume no aliasing and move from the parameter" to be interpreted as "the compiler can assume this is a globally unique reference that aliases nothing and optimize based on that" -- that seems too aggressive.

The intent is that functions like vector::push_back(value_type&&) don't need to handle vec.push_back(std::move(vec.front()). The lvalue overload of vector::push_back(const value_type&) does need to support vec.push_back(vec.front()), which requires some subtleties in the impl. If the user passes an rvalue, it should not be something that is "temporary-like", i.e. it doesn't have to be an actual prvalue, but it should be some object for which the caller has "ownership" (in some vague sense of ownership) like a local variable in the caller, and not something that "belongs" to the vector, or another object the library might access.

[ogiroux]

SG1 in Sofia : we believe the "whole program scope" is not relevant and what you want is more narrowly limited to objects that can be reached within reasonable compiler perspicacity (Davis' words). The reference need not even be unique within the scope of one function and still you'd want to enable the vector resizing proactively, for example:

void wrap_push_back(std::vector<X> &v, X &&x) {  // x is not an element of v
  v.push_back(std::move(x));  // UB(?!): there are two (rvalue) references to this object, x and the parameter to std::vector::push_back
}