title: Implicitly treating returned lvalue as rvalue
body: <p>12.8 Copying and moving class objects [class.copy] §31 and §32 say:</p>
  <blockquote>
  <p>in a return statement in a function with a class return type, <strong>when the expression is the name</strong> of a non-volatile automatic object (other than a function or catch-clause parameter) with the same cv-unqualified type as the function return type, the copy/move operation can be omitted by constructing the automatic object directly into the function’s return value</p>
  <p>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.</p>
  </blockquote>
  <p>Hence we can write:</p>
  <pre><code>unique_ptr&lt;int&gt; make_answer()
  {
      unique_ptr&lt;int&gt; result(new int(42));
      return result;   // lvalue is implicitly treated as rvalue
  }
  </code></pre>
  <p>However, I noticed that g++ 4.6.3 also accepts lvalues that are <strong>not names</strong>, for example:</p>
  <pre><code>    return (result);
      return *&amp;result;
      return true ? result : result;
  </code></pre>
  <p>By contrast, <code>return rand() ? result : result;</code> does not work. Is the compiler's optimizer interfering with the language semantics? As I interpret the standard, <code>return (result);</code> should not compile, because <code>(result)</code> is not a name, but a parenthesized expression. Am I right or wrong?</p>