Clarify the ambiguous meaning arising from [expr.call] and [stmt.return]

[xmh0511]

Full name of submitter (unless configured in github; will be published with the issue): Jim X

The issues in https://github.com/cplusplus/draft/issues/4723, https://github.com/cplusplus/draft/issues/4847, https://github.com/cplusplus/draft/pull/4107, https://github.com/cplusplus/draft/issues/4847, https://github.com/cplusplus/CWG/issues/159, and https://github.com/cplusplus/draft/issues/6001 (maybe omit some other issues) can all be subsumed to the issue that:

the result of the function call is not clear, and certain rules defined in [stmt.return] conflict with that of [expr.call]

Suggested resolution

We can just say

The return statement with operand models a declaration T v = E; where T is the return type of the function and E is (expr-or-braced-init-list) if the expr-or-braced-init-list of the return statement is an expression and is expr-or-braced-init-list otherwise, v is an lvalue if T is an lvalue reference type or an rvalue reference to function type , an xvalue if T is an rvalue reference to object type, and a prvalue otherwise. The result of the function call is the v established by the return statement that transferred the flow control.

The copy-initialization of the result object of the call is sequenced before the destruction of local variables ([stmt.jump]) of the block enclosing the return statement.

This definition keeps the consistent meaning with the initialization that occurs in a return statement, and the lifetime of temporary objects created in the return statement, in the current draft.

[tkoeppe]

Could you kindly close all the editorial issues and refer them to this Core issue instead? I think we won't make changes of this kind editorially in any case. Thanks!

[xmh0511]

Thanks for your reminder, I have closed them by referring to this issue.