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

reconsider placeholder formatting in [expr.await] #2774

Closed
zygoloid opened this issue Mar 13, 2019 · 4 comments
Closed

reconsider placeholder formatting in [expr.await] #2774

zygoloid opened this issue Mar 13, 2019 · 4 comments

Comments

@zygoloid
Copy link
Member

[expr.await] uses placeholders for names of various expressions, types, etc used in its exposition. We should consider whether plain teletype would be a better choice for some of those placeholders (in particular, the ones that simply denote types rather than being syntactic macros for a choice of one of two forms of expression).

@zygoloid
Copy link
Member Author

Concretely, we should consider upright teletype for these placeholders: P and Z (types), and e and h (objects). p, a, o, await-ready, await-suspend, and await-resume are all macros for a specific syntactic construct, so italics for those seems appropriate.

@zygoloid
Copy link
Member Author

It's not clear what to do with s in /5.1, which is "a value". But then we talk about a call "s.resume()", which doesn't make sense, since you can't make a call on a value. I think s should actually be the await-suspend expression itself:

If the await-suspend expression has type std::coroutine_handle<Z>, the coroutine referred to by that handle is resumed as if by calling await-suspend.resume().

Fitting that into the surrounding bullet may require some massaging of the text.

@zygoloid
Copy link
Member Author

e and h are nebulous -- e is an lvalue, and h should probably be a prvalue, so they're both syntax-macro-esque.

@jensmaurer
Copy link
Member

Waiting for #2770.

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