Are returned locals automatically xvalues

Question

Following on from a comment I made on this:

passing std::vector to constructor and move semantics Is the std::move necessary in the following code, to e

Answer 1

Altough both, return std::move(local) and return local, do work in sense of that they do compile, their behavior is different. And probably only the latter one was intended.

If you write a function which returns a std::vector<string>, you have to return a std::vector<string> and exactly it. std::move(local) has the typestd::vector<string>&& which is not a std::vector<string> so it has to be converted to it using the move constructor.

The standard says in 6.6.3.2:

The value of the expression is implicitly converted to the return type of the function in which it appears.

That means, return std::move(local) is equalvalent to

std::vector<std::string> converted(std::move(local); // move constructor
return converted; // not yet a copy constructor call (which will be elided anyway)

whereas return local only is

return local; // not yet a copy constructor call (which will be elided anyway)

This spares you one operation.

---

To give you a short example of what that means:

struct test {
  test() { std::cout << "  construct\n"; }
  test(const test&) { std::cout << "  copy\n"; }
  test(test&&) { std::cout << "  move\n"; }
};

test f1() { test t; return t; }
test f2() { test t; return std::move(t); }

int main()
{
  std::cout << "f1():\n"; test t1 = f1();
  std::cout << "f2():\n"; test t2 = f2();
}

This will output

f1():
  construct
f2():
  construct
  move

Answer 2

You're guaranteed that local will be returned as an rvalue in this situation. Usually compilers would perform return-value optimization though before this even becomes an issue, and you probably wouldn't see any actual move at all, since the local object would be constructed directly at the call site.

A relevant Note in 6.6.3 ["The return statement"] (2):

A copy or move operation associated with a return statement may be elided or considered as an rvalue for the purpose of overload resolution in selecting a constructor (12.8).

To clarify, this is to say that the returned object can be move-constructed from the local object (even though in practice RVO will skip this step entirely). The normative part of the standard is 12.8 ["Copying and moving class objects"] (31, 32), on copy elision and rvalues (thanks @Mankarse!).

---

Here's a silly example:

#include <utility>

struct Foo
{
    Foo()            = default;
    Foo(Foo const &) = delete;
    Foo(Foo &&)      = default;
};

Foo f(Foo & x)
{
    Foo y;

    // return x;         // error: use of deleted function ‘Foo::Foo(const Foo&)’
    return std::move(x); // OK
    return std::move(y); // OK
    return y;            // OK (!!)
}

Contrast this with returning an actual rvalue reference:

Foo && g()
{
    Foo y;
    // return y;         // error: cannot bind ‘Foo’ lvalue to ‘Foo&&’
    return std::move(y); // OK type-wise (but undefined behaviour, thanks @GMNG)
}

Answer 3

I think the answer is no. Though officially only a note, §5/6 summarizes what expressions are/aren't xvalues:

An expression is an xvalue if it is:

• the result of calling a function, whether implicitly or explicitly, whose return type is an rvalue reference to object type,
• a cast to an rvalue reference to object type,
• a class member access expression designating a non-static data member of non-reference type in which the object expression is an xvalue, or
• a .* pointer-to-member expression in which the first operand is an xvalue and the second operand is a pointer to data member.

In general, the effect of this rule is that named rvalue references are treated as lvalues and unnamed rvalue references to objects are treated as xvalues; rvalue references to functions are treated as lvalues whether named or not.

The first bullet point seems to apply here. Since the function in question returns a value rather than an rvalue reference, the result won't be an xvalue.