Why would const-ness of a local variable inhibit move semantics for the returned value?

struct STest : public boost::noncopyable { STest(STest && test) : m_n( std::move(test.m_n) ) {} explicit STest(int n) : m_n(n) {} int m_n; }; STest FuncUsingConst(int n) { STest const a(n); return a; } STest FuncWithoutConst(int n) { STest a(n); return a; } void Caller() { // 1. compiles just fine and uses move ctor STest s1( FuncWithoutConst(17) ); // 2. does not compile (cannot use move ctor, tries to use copy ctor) STest s2( FuncUsingConst(17) ); } 

The above example illustrates how in C++11, as implemented in Microsoft Visual C++ 2012, the internal details of a function can modify its return type. Up until today, it was my understanding that the declaration of the return type is all a programmer needs to know to understand how the return value will be treated, e.g., when passed as a parameter to a subsequent function call. Not so.

I like making local variables const where appropriate. It helps me clean up my train of thought and clearly structure an algorithm. But beware of returning a variable that was declared const! Even though the variable will no longer be accessed (a return statement was executed, after all), and even though the variable that was declared const has long gone out of scope (evaluation of the parameter expression is complete), it cannot be moved and thus will be copied (or fail to compile if copying is not possible).

This question is related to another question, Move semantics & returning const values. The difference is that in the latter, the function is declared to return a const value. In my example, FuncUsingConst is declared to return a volatile temporary. Yet, the implementational details of the function body affect the type of the return value, and determine whether or not the returned value can be used as a parameter to other functions.

Is this behavior intended by the standard?
How can this be regarded useful?

Bonus question: How can the compiler know the difference at compile time, given that the call and the implementation may be in different translation units?

EDIT: An attempt to rephrase the question.

How is it possible that there is more to the result of a function than the declared return type? How does it even seem acceptable at all that the function declaration is not sufficient to determine the behavior of the function's returned value? To me that seems to be a case of FUBAR and I'm just not sure whether to blame the standard or Microsoft's implementation thereof.

As the implementer of the called function, I cannot be expected to even know all callers, let alone monitor every little change in the calling code. On the other hand, as the implementer of the calling function, I cannot rely on the called function to not return a variable that happens to be declared const within the scope of the function implementation.

A function declaration is a contract. What is it worth now? We are not talking about a semantically equivalent compiler optimization here, like copy elision, which is nice to have but does not change the meaning of code. Whether or not the copy ctor is called does change the meaning of code (and can even break the code to a degree that it cannot be compiled, as illustrated above). To appreciate the awkwardness of what I am discussing here, consider the "bonus question" above.