Why does std::move take a forward reference?

Question

The implementation of std::move basically looks like this:

template<typename T>
typename std::remove_reference<T>::type&&
move(T&& t)
{
    return static_cast<typename std::remove_reference<T>::type&&>(t);
}

Note that the parameter of std::move is a universal reference (also known as a forwarding reference, but we're not forwarding here). That is, you can std::move both lvalues and rvalues:

std::string a, b, c;
// ...
foo(std::move(a));       // fine, a is an lvalue
foo(std::move(b + c));   // nonsense, b + c is already an rvalue

But since the whole point of std::move is to cast to an rvalue, why are we even allowed to std::move rvalues? Wouldn't it make more sense if std::move would only accept lvalues?

template<typename T>
T&&
move(T& t)
{
    return static_cast<T&&>(t);
}

Then the nonsensical expression std::move(b + c) would cause a compile-time error.

The above implementation of std::move would also be much easier to understand for beginners, because the code does exactly what it appears to do: It takes an lvalue and returns an rvalue. You don't have to understand universal references, reference collapsing and meta functions.

So why was std::move designed to take both lvalues and rvalues?

My quick guess would be that when you write code to move things around you don't want to be constantly thinking whether your variables are lvalues or rvalues, you just want to do it. — sim642
Because it is designed to cast both lvalue and rvalue to rvalue unconditionally. — user2486888
@6502 And rants don't belong on stack overflow, wouldn't you agree? — fredoverflow
In generic code sometimes you do not know if an expression is an lvalue or an rvalue (function calls, for instance), but may want to unconditionally move from it. Also, allowing the quasi-identity rvalue-to-rvalue cast isn't dangerous, so there isn't a compelling reason to prohibit it. But I suspect only Howard Hinnant knows the real reason... — T.C.
@Galik this is a bit of a misconception. When you apply std::move(x) inside some template <T> f(T&& x), then x is a lvalue of type rvalue reference (in case a rvalue was passed). So you actually apply std::move on a lvalue in this case. But I guess the problem appears when doing something like std::move(f()), and you may not know whether f returns a lvalue reference or a rvalue. — vsoftco

vsoftco vsoftco · Accepted Answer · 2015-03-09T07:28:47

Here is some example simplified to the extreme:

#include <iostream>
#include <vector>

template<typename T>
T&& my_move(T& t)
{
    return static_cast<T&&>(t);
}

int main() 
{
    std::vector<bool> v{true};

    std::move(v[0]); // std::move on rvalue, OK
    my_move(v[0]);   // my_move on rvalue, OOPS
}

Cases like the one above may appear in generic code, for example when using containers which have specializations that return proxy objects (rvalues), and you may not know whether the client will be using the specialization or not, so you want unconditional support for move semantics.

Why does std::move take a forward reference?

2 Answers