[class.copy.elision] Move specification of altered overload resolution #3998
Conversation
zygoloid
added
the
needs rebase
jensmaurer
removed
the
needs rebase
(which prefers moving over copying) to [dcl.init] and [expr.call]. Also add and adjust cross-references in [stmt.return], [stmt.return.coroutine] and [except.throw].
| For result-initialization, | ||
| overload resolution is first performed as if the operand were an rvalue. | ||
| For any other initialization, or if the first overload resolution fails, | ||
| overload resolution is performed again without altering value categories. |
There was a problem hiding this comment.
FWIW, it's unclear what the word "again" is doing here.
| of the innermost \grammarterm{try-block} or \grammarterm{function-try-block} | ||
| (if any) | ||
| whose \grammarterm{compound-statement} or \grammarterm{ctor-initializer} | ||
| encloses the \grammarterm{throw-expression}, |
| @@ -6629,102 +6629,6 @@ | |||
| move construction from the object with automatic storage duration to \tcode{t2} that is elided. | |||
| \end{example} | |||
|
|
|||
| \pnum | |||
There was a problem hiding this comment.
FWIW, this refactoring merge-conflicts with the paper D2266 I've just started writing to clean up the semantics of implicit move. See https://quuxplusone.github.io/draft/d2266-implicit-move-rvalue-ref.html (which will at some point become https://wg21.link/p2266, I expect).
So basically I'm not in favor of any such major wording-moving-around, until we've finished figuring out what the wording should say. At least it'd be nice to avoid duplicating it in multiple places.
There was a problem hiding this comment.
My fundamental concern with the status quo is that mandatory behavior is hidden in a "copy elision" section, without any first-order connection to where the grammar appears (stmt.return etc.) If your paper would do the move, that's fine as well.
There was a problem hiding this comment.
Well, @zygoloid's review feedback on the above iteration of D2266 (R0 draft revision 1) is that my wording change is totally in the wrong place and ought to be somewhere more like https://eel.is/c++draft/basic.lval . (However, I can't find any current wording that clearly states "an id-expression is an lvalue"; if such wording existed, presumably that'd be the place for me to try changing.)
So I no longer object to shuffling this wording around.
The new term of art "result-initialization" is intended to be useful for more than just implicit-move, right? Because if D2266 ends up changing the value-category of an implicitly-movable id-expression, then we won't need any wording to describe implicit-move anymore.
There was a problem hiding this comment.
This pull request (and the associated copy elision wording) will probably vanish entirely with your paper.
The wording that an id-expression is an lvalue is in [expr.prim.id.unqual] and siblings.
| For result-initialization, overload resolution is first performed | ||
| as if the operand were an rvalue. | ||
| For any other initialization, or if the first overload resolution fails, | ||
| overload resolution is performed again without altering value categories. |
There was a problem hiding this comment.
Again "again" doesn't seem to apply to non-result-initializations.
| @@ -914,6 +915,10 @@ | |||
| If the operand is a \grammarterm{braced-init-list} or an expression of non-\tcode{void} type, | |||
| \placeholder{S} is \placeholder{p}\tcode{.return_value(}\grammarterm{expr-or-braced-init-list}{}\tcode{)}. | |||
| The expression \placeholder{S} shall be a prvalue of type \tcode{void}. | |||
| \begin{note} | |||
| The operand might be moved instead of copied; | |||
There was a problem hiding this comment.
s/might/can/, since we're doing that phrasing now?
| that is either a non-volatile object or | ||
| an rvalue reference to a non-volatile object type. | ||
| The copy-initialization performed for one of the following is | ||
| known as \defn{result-initialization}: |
There was a problem hiding this comment.
Surely it's the initialization performed from one of these, right? It's not the initialization of the operand of the return statement; it's the initialization of the returned object, which is copy-initialized from the operand of the return.
Same comment down where you talk about a co_return statement "whose operand is subject to result-initialization." The operand is actually used to result-initialize whatever is passed to return_value.
tkoeppe
added
the
needs rebase
|
This pull request will be superseded by P2266 Simpler implicit move cplusplus/papers#968. |
|
@jensmaurer Can we close this now? |
|
Yes |
(which prefers moving over copying) to [dcl.init] and [expr.call].
Also add and adjust cross-references in [stmt.return],
[stmt.return.coroutine] and [except.throw].
Fixes #3818