Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
xmh0511 opened this issue Nov 29, 2022 · 2 comments
Open

Comments

@xmh0511
Copy link

xmh0511 commented Nov 29, 2022

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

The issues in cplusplus/draft#4723, cplusplus/draft#4847, cplusplus/draft#4107, cplusplus/draft#4847, #159, and cplusplus/draft#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
Copy link

tkoeppe commented Nov 29, 2022

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
Copy link
Author

xmh0511 commented Nov 30, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants