Why are the RVO requirements so restrictive? : <p>Yet another "why must <code>std::move</code> prevent the (unnamed) return-value-optimization?" question:</p>

<p><a href="https://stackoverflow.com/questions/19267408/why-does-stdmove-prevent-rvo">Why does std::move prevent RVO?</a> explains that the standard specifically requires that the function's declared return type must match the type of the expression in the <code>return</code> statement.  That explains the behavior of conforming compilers; however, it does not explain the rationale for the restriction.</p>

<p>Why do the rules for RVO not make an exception for the case where the function's return type is <code>T</code> and the type of the <code>return</code> expression is <code>T&amp;&amp;</code>?</p>

<p>I also am aware that implementing such things in compilers doesn't come for free.  I am suggesting only that such an exception be allowed but not required.</p>

<p>I also am aware that <code>return std::move(...)</code> is unnecessary since C++11 <a href="https://youtu.be/AKtHxKJRwp4?t=2359" rel="noreferrer">already requires that move semantics be used when the RVO can't be applied</a>.  Nevertheless, why not tolerate an explicit request for optimization instead of turning it into a pessimization?</p>

<hr>

<p>(Aside: Why are the <code>return-value-optimization</code> and <code>rvo</code> tags not synonyms?)</p>
