Are value parameters implicitly moved when returned by value?

Consider the following function:

Foo foo(Foo x)
{
    return x;
}

Will return x invoke the copy constructor or the move constructor? (Let's leave NRVO aside here.)

To investigate, I wrote a simple Foo class that is only movable but not copyable:

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

If the move constructor were invoked when returning value parameters by value, all should be fine. But the current g++ com开发者_开发知识库piler complains about return x with the following error message:

error: deleted function 'Foo::Foo(const Foo&)'

If I replace return x with return std::move(x), everything is fine. From this I conclude that moving from value parameters must be done explicitly if desired. Is g++'s behavior conforming or not?

If there is a move ctor for Foo, it should be selected.

Function parameters are explicitly excluded from copy elision in return statements (FDIS §12.9p31, first bullet):

• in a return statement in a function with a class return type, when the expression is the name of a non-volatile automatic object (other than a function or catch-clause parameter)

However, the next paragraph explicitly brings move ctors back into consideration:

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. …

(Emphasis is mine in both quotes.)

This is valid code- G++'s behaviour is non-conformant. MSVC10 does support this behaviour.