When should std::move be used on a function return value?

In this case

struct Foo {};
Foo meh() {
  return std::move(Foo());
}

I'm pretty sure that the move is unnecessary, because the newly created Foo will be an xvalue.

But what in cases like these?

struct Foo {};
Foo meh() {
  Foo foo;
  //do something, but knowing that foo can safely be disposed of
  //but does the compiler necessarily know it?
  //we may have references/pointers to foo. how could the compiler know?
  return std::move(foo); //so here the move is needed, right?
}

There the move is needed, I suppose?

In the case of return std::move(foo); the move is superfluous because of 12.8/32:

> When the criteria for elision of a copy operation are met or would be > met save for the fact that the source object is a function parameter, > and the object to be copied is designated by an lvalue, overload > resolution to select the constructor for the copy is first performed as > if the object were designated by an rvalue.

return foo; is a case of NRVO, so copy elision is permitted. foo is an lvalue. So the constructor selected for the "copy" from foo to the return value of meh is required to be the move constructor if one exists.

Adding move does have a potential effect, though: it prevents the move being elided, because return std::move(foo); is not eligible for NRVO.

As far as I know, 12.8/32 lays out the only conditions under which a copy from an lvalue can be replaced by a move. The compiler is not permitted in general to detect that an lvalue is unused after the copy (using DFA, say), and make the change on its own initiative. I'm assuming here that there's an observable difference between the two -- if the observable behavior is the same then the "as-if" rule applies.

So, to answer the question in the title, use std::move on a return value when you want it to be moved and it would not get moved anyway. That is:

• you want it to be moved, and
• it is an lvalue, and
• it is not eligible for copy elision, and
• it is not the name of a by-value function parameter.

Considering that this is quite fiddly and moves are usually cheap, you might like to say that in non-template code you can simplify this a bit. Use std::move when:

• you want it to be moved, and
• it is an lvalue, and
• you can't be bothered worrying about it.

By following the simplified rules you sacrifice some move elision. For types like std::vector that are cheap to move you'll probably never notice (and if you do notice you can optimize). For types like std::array that are expensive to move, or for templates where you have no idea whether moves are cheap or not, you're more likely to be bothered worrying about it.

The move is unnecessary in both cases. In the second case, std::move is superfluous because you are returning a local variable by value, and the compiler will understand that since you're not going to use that local variable anymore, it can be moved from rather than being copied.

On a return value, if the return expression refers directly to the name of a local lvalue (i.e. at this point an xvalue) there is no need for the std::move. On the other hand, if the return expression is not the identifier, it will not be moved automatically, so for example, you would need the explicit std::move in this case:

T foo(bool which) {
   T a = ..., b = ...;
   return std::move(which? a : b);
   // alternatively: return which? std::move(a), std::move(b);
}

When returning a named local variable or a temporary expression directly, you should avoid the explicit std::move. The compiler must (and will in the future) move automatically in those cases, and adding std::move might affect other optimizations.

There are lots of answers about when it shouldn't be moved, but the question is "when should it be moved?"

Here is a contrived example of when it should be used:

std::vector<int> append(std::vector<int>&& v, int x) {
  v.push_back(x);
  return std::move(v);
}

ie, when you have a function that takes an rvalue reference, modifies it, and then returns a copy of it. (In [tag:C++20] behavior here changes) Now, in practice, this design is almost always better:

std::vector<int> append(std::vector<int> v, int x) {
  v.push_back(x);
  return v;
}

which also allows you to take non-rvalue parameters.

Basically, if you have an rvalue reference within a function that you want to return by moving, you have to call std::move. If you have a local variable (be it a parameter or not), returning it implicitly moves (and this implicit move can be elided away, while an explicit move cannot). If you have a function or operation that takes local variables, and returns a reference to said local variable, you have to std::move to get move to occur (as an example, the trinary ?: operator).

A C++ compiler is free to use std::move(foo):

• if it is known that foo is at the end of its lifetime, and
• the implicit use of std::move won't have any effect on the semantics of the C++ code other than the semantic effects allowed by the C++ specification.

It depends on the optimization capabilities of the C++ compiler whether it is able to compute which transformations from f(foo); foo.~Foo(); to f(std::move(foo)); foo.~Foo(); are profitable in terms of performance or in terms of memory consumption, while adhering to the C++ specification rules.

---

Conceptually speaking, year-2017 C++ compilers, such as GCC 6.3.0, are able to optimize this code:

Foo meh() {
    Foo foo(args);
    foo.method(xyz);
    bar();
    return foo;
}

into this code:

void meh(Foo *retval) {
   new (retval) Foo(arg);
   retval->method(xyz);
   bar();
}

which avoids calling the copy-constructor and the destructor of Foo.

---

Year-2017 C++ compilers, such as GCC 6.3.0, are unable to optimize these codes:

Foo meh_value() {
    Foo foo(args);
    Foo retval(foo);
    return retval;
}

Foo meh_pointer() {
    Foo *foo = get_foo();
    Foo retval(*foo);
    delete foo;
    return retval;
}

into these codes:

Foo meh_value() {
    Foo foo(args);
    Foo retval(std::move(foo));
    return retval;
}

Foo meh_pointer() {
    Foo *foo = get_foo();
    Foo retval(std::move(*foo));
    delete foo;
    return retval;
}

which means that a year-2017 programmer needs to specify such optimizations explicitly.

std::move is totally unnecessary when returning from a function, and really gets into the realm of you -- the programmer -- trying to babysit things that you should leave to the compiler.

What happens when you std::move something out of a function that isn't a variable local to that function? You can say that you'll never write code like that, but what happens if you write code that's just fine, and then refactor it and absent-mindedly don't change the std::move. You'll have fun tracking that bug down.

The compiler, on the other hand, is mostly incapable of making these kinds of mistakes.

Also: Important to note that returning a local variable from a function does not necessarily create an rvalue or use move semantics.

See here.