implicitly-move-from-rvalue-references-in-return-statements.html

<h1 id="implicitly-move-from-rvalue-references-in-return-statements">Implicitly move from rvalue references in return statements</h1>

<p>Document number: P0527R1 <br>
Date: 2017-11-08 <br>
Project: Programming Language C++, Core Working Group <br>
Reply-to: David Stone: &#x64;&#x61;&#x76;&#x69;&#x64;&#x6D;&#x73;&#x74;&#x6F;&#x6E;&#x65;&#x40;&#x67;&#x6F;&#x6F;&#x67;&#x6C;&#x65;&#x2E;&#x63;&#x6F;&#x6D;</p>

<h2 id="introduction">Introduction</h2>

<p>A function return statement will automatically invoke a move rather than a copy in some situations. This proposal slightly extends those situations.</p>

<p>This proposal was approved by EWG in the Kona 2017 meeting.</p>



<h2 id="return-statements">Return Statements</h2>

<p>We already have implicit moves for local values and function parameters in a return statement. The following code compiles just fine:</p>

<pre><code>    std::unique_ptr&lt;T&gt; f(std::unique_ptr&lt;T&gt; ptr) {
        return ptr;
    }
</code></pre>

<p>However, the following code does not compile</p>

<pre><code>    std::unique_ptr&lt;T&gt; f(std::unique_ptr&lt;T&gt; &amp;&amp; ptr) {
        return ptr;
    }
</code></pre>

<p>Instead, you must type</p>

<pre><code>    std::unique_ptr&lt;T&gt; f(std::unique_ptr&lt;T&gt; &amp;&amp; ptr) {
        return std::move(ptr);
    }
</code></pre>

<p>This extra typing is unnecessary and leads to possible inefficiencies. Consider the generic case:</p>

<pre><code>    auto f(args...) {
        decltype(auto) result = some_other_function();
        return std::forward&lt;decltype(result)&gt;(result);
    }
</code></pre>

<p>Now we have inhibited return-value optimization (RVO) in the case where <code>result</code> is a value and not a reference, but without the <code>std::forward</code>, the code does not compile if <code>result</code> is an rvalue reference and is move-only.</p>

<pre><code>    auto f(T &amp;&amp; value) {
        // do stuff with value
        return value;
    }
</code></pre>

<p>Using move constructors instead of copy constructors can be critical for writing high-performance C++ code. However, due to the rules of when a move is invoked in a return statement, a user who knows most (but not all) of the rules is likely to accidentally invoke a copy when they mean to invoke a move.</p>

<p>For instance, consider the following two functions:</p>

<pre><code>    std::string f(std::string x) { return x; }
    std::string g(std::string &amp;&amp; x) { return x; }
</code></pre>

<p>The function <code>f</code> will invoke the move constructor of <code>x</code>, but the function <code>g</code> will invoke the copy constructor.</p>

<p>I believe that it is more surprising to the user that a move does not occur in this situation than it would be if a move did occur. The only way to get an rvalue reference to something is if it was bound to a prvalue or if the user explicitly called <code>std::move</code> or equivalent. This means that either it is definitely safe (due to being bound to a prvalue) or the user explicitly opted in to moves at some point.</p>



<h2 id="throw-expressions">Throw Expressions</h2>

<p>Current rules also prevent the compiler from implicitly moving from function parameters in any situation for a throw expression. However, at least one production compiler (clang) does not implement this correctly and implicitly moves from function parameters. This proposal also extends these rules to throw expressions, requiring using a move instead of a copy for local variable and function parameter objects and rvalue references. This proposal also removes the restriction on implicitly moving from a catch-clause parameter in a throw expression. At least one production compiler (gcc) does not implement this correctly and implicitly moves from catch-clause parameters in throw expressions.</p>

<p>This does not cause problems with function parameters and function-scope try-blocks because there is already a rule preventing crossing try-block scope boundaries in implicit moves.</p>

<p>This proposal unifies the treatment of return statements and throw expressions.</p>



<h2 id="effect-on-the-standard-library">Effect On the Standard Library</h2>

<p>This proposal is unlikely to have any effect on the standard library, as we typically do not describe function bodies, but rather, function signatures.</p>



<h2 id="wording">Wording</h2>

<p>Change in 15.8.3 (class.copy.elision), paragraph 3:</p>

<blockquote>
  <p><ins>A movable entity is a non-volatile object or an rvalue reference to a non-volatile type, in either case with automatic storage duration. The underlying type of a movable entity is the type of the object or the referenced type, respectively.</ins> In the following copy-initialization contexts, a move operation might be used instead of a copy operation:</p>
  
  <ul>
  <li>If the expression in a return statement is a (possibly parenthesized) id-expression that names <ins>a movable entity</ins> <del>an object with automatic storage duration</del> declared in the body or parameter-declaration-clause of the innermost enclosing function or lambda-expression, or</li>
  <li>if the operand of a throw-expression is <ins>a (possibly parenthesized) id-expression that names a movable entity</ins> <del>the name of a non-volatile automatic object (other than a function or catch-clause parameter)</del> whose scope does not extend beyond the end of the innermost enclosing try-block (if there is one), </li>
  </ul>
  
  <p>overload resolution to select the constructor for the copy is first performed as if the <ins>entity</ins> <del>object</del> were designated by an rvalue. If the first overload resolution fails or was not performed, or if the type of the first parameter of the selected constructor is not an rvalue reference to the <ins>(possibly cv-qualified) underlying type of the movable entity</ins> <del>object's type (possibly cv-qualified)</del>, overload resolution is performed again, considering the <ins>entity</ins> <del>object</del> as an lvalue.</p>
</blockquote>

<p>Alternatively, we could replace the two bullets with the following sentence:</p>

<blockquote>
  <p><ins>If the operand of a throw expression or the expression in a return statement is a (possibly parenthesized) id-expression that names a movable entity whose scope does not extend beyond the end of the innermost enclosing try-block (if any), or function or lambda-expression, respectively,</ins></p>
</blockquote>

<h2 id="acknowledgements">Acknowledgements</h2>

<p>Thanks to Jens Maurer for helping me draft the wording for this proposal.</p>