why is returning rvalue reference wrong

Question

I was wondering what went wrong in having a r-reference return type like:

vector<T>&& id2(vector<T>&& v) {  return std::move(v);}

as in the code below. Doing a = id2(a) sets empty. The other version id returning the normal type is OK.

I heard this has something to do with self-move assignment. But I only have a basic knowledge about move semantics, and I don't understand the cryptic language in the answer there quoted from the standards. Can someone please explain this in common-sense/layman's language?

If I take a temporary a, reap out its content and return the content as a temporary to be assigned back to a, why should a be cleared or undefined?

#include <vector>
#include <iostream>
using namespace std;

template <class T>
vector<T> id(vector<T>&& v) {  return std::move(v); }

template <class T>
vector<T>&& id2(vector<T>&& v) {  return std::move(v);}

int main() {
  vector<int> a;
  a.resize(3,1);
  a = id(std::move(a));
  cout << a.size() << endl;  //output: 3

  a.resize(3,1);
  a = id2(std::move(a));
  cout << a.size() << endl;  //output: 0
}

Thanks,

-- Update ---

If I am reading the said duplicate post, the second example there quoted below was about passing r-ref to a local variable outside a function, which is an error anyway regardless of this is a r-ref or l-ref. I don't think that's quite the same as my example. If you use left reference instead of r-ref in my example, it would have worked. Am I missing something on this?

std::vector<int>&& return_vector(void)
{
    std::vector<int> tmp {1,2,3,4,5};
    return std::move(tmp);
}

std::vector<int> &&rval_ref = return_vector();

--- Update 2 ---

@pradhan. It seems that the issue boils down to self-move assignment. Regarding the library choice of behavior on self-move assignment for standard containers, this is what bothers me. If you do a self-assign of std::vector in the old fashion, it's perfectly fine, but when you self-move assign, it's undefined behavior. Unless there is something inherently wrong, is it more natural (backward compatible) to have standard containers allow self-move assign as with self-assign?

#include <vector>
#include <iostream>

int main() {
  std::vector<int>a{1,2,3};
  a = a;
  std::cout << a.size() << std::endl;  //output: 3
  a = std::move(a);
  std::cout << a.size() << std::endl;  //output: 0
}

Answer 1

Your function id2 does nothing, the code is equivalent to

a = std::move(a);

The answer from Howard Hinnant you linked explains that this is in itself not allowed. In layman's terms: The standard does not require self-move assignment to be supported. Thus an implementation of a move-assignment operator is not required to perform a test for self-assignment and the result us undefined behavior.

If you would make a=std::move(a) legal, it would do nothing. The problem is that this requires a check which is superfluous for the non-self move-assignment case and therefore pessimize all those assignments.

Answer 2

You're violating the convention (which is a requirement for calls to library functions) that rvalue references do not alias. Howard Hinnant's answer, referred to in the question, contains the standard text and the application to self-move. Here's the practical result:

It's both legal and common to implement move-assignment as:

T& T::operator=(T&& other)
{
    clear();
    swap(*this, other);
    return *this;
}

or the more exception-safe variant:

T& T::operator=(T&& other)
{
    swap(*this, other);
    other.clear();
    return *this;
}

and as long as the aliasing convention is observed, this is also safe.

It's pretty clear why either of these implementations would yield an empty object if you do alias.

BTW, there's nothing wrong with id2 that returns an rvalue reference. The problem is with a = id2(a); which uses an rvalue reference that aliases another object reference in the same expression.

Answer 3

The link from your question and Hinnant's answer both deal with the requirement placed by the standard on implementations of the standard library. There is nothing inherently wrong with a=std::move(a). If a is of class type T, the result of a=std::move(a) depends on the implementation of T. The standard allows the (standard)library implementations to make the unique reference assumption when given an rvalue reference argument. When a has type T=vector<U>, a=std::move(a) violates the unique reference assumption. Since you are breaking the library contract, it results in UB. However, you could have your own class whose move constructor implementation has a perfectly well-defined behaviour wrt a=std::move(a). The standard doesn't say anything about self-move assignment in general. It only specifies what the standard library implementors are required to support and what they can choose not to, if it pleases them.