Skip to content
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

CWG2934 [dcl.fct.def.coroutine] Unclear semantics of exception escaping from unhandled_exception #574

Open
t3nsor opened this issue Jul 13, 2024 · 5 comments

Comments

@t3nsor
Copy link

t3nsor commented Jul 13, 2024

Full name of submitter: Brian Bi

Reference (section label): [dcl.fct.def.coroutine]

Issue description: [dcl.fct.def.coroutine]/14 says:

If the evaluation of the expression promise.unhandled_exception() exits via an exception, the coroutine is considered suspended at the final suspend point and the exception propagates to the caller or resumer.

All implementations first destroy the promise object followed by the parameter copies, then deallocate the coroutine state, and finally return control to the caller: https://godbolt.org/z/e7edh8d9o

The behaviour of the implementations is expected based on the code in [dcl.fct.def.coroutine]/5, but the wording in p14 suggests that suspension occurs immediately when unhandled_exception() exits, prior to any stack unwinding in the coroutine. The intent should be clarified.

@t3nsor
Copy link
Author

t3nsor commented Jul 13, 2024

Prior discussion can be found here and here.

@t3nsor
Copy link
Author

t3nsor commented Sep 9, 2024

Bump

@jensmaurer
Copy link
Member

Any wording suggestion?

@jensmaurer
Copy link
Member

CWG2934

@jensmaurer jensmaurer changed the title [dcl.fct.def.coroutine] Unclear semantics of exception escaping from unhandled_exception CWG2934 [dcl.fct.def.coroutine] Unclear semantics of exception escaping from unhandled_exception Sep 9, 2024
@t3nsor
Copy link
Author

t3nsor commented Sep 10, 2024

I think the reason why I didn't write a wording suggestion for this one is that it depends on what we decide we want for [CWG2935]. The wording is cleaner if we assume that an exception propagating out of the coroutine always destroys the coroutine state.

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