Skip to content

[expr.await] need a term to refer to the transformations applied to the co_await operand #250

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
ericniebler opened this issue Mar 1, 2023 · 1 comment

Comments

@ericniebler
Copy link

ericniebler commented Mar 1, 2023

Full name of submitter:
Eric Niebler

Reference (section label):
[expr.await]

Link to reflector thread (if any):
NA

Issue description:
Paragraphs [expr.await]/3.2 through 3.4 describe a series of transformations that the compiler applies to a cast-expression when it is the operand of co_await, ending in an lvalue e referring to the object o produced by the transformations. These transformations have no label to which another section may refer back to the them.

I would like a way to refer back to these transformations in order to describe the behavior of some coroutine-related library functionality. As these transformations are not expressible in pure library code, I need a core term to conveniently refer back to them in a way that is not likely to change during edit passes. (Referring to paragraph numbers or expression names like e and o being error prone and hard to grep for.)

Suggested resolution:
Define a pseudo-macro or pseudo-intrinsic that, given a cast-expression and an lvalue to a coroutine promise type p, evaluates to the lvalue e defined in [expr.await]/3.4. Something like:

    get-awaiter(cast-expression, p)

It may even be desirable to separate the transformations effected by the invocation of await_transform and operator co_await:

    get-awaiter(get-awaitable(cast-expression, p))

... where get-awaitable applies the promise's await_transform if any, and get-awaiter applies the operator co_await selected by overload resolution if any.

These pseudo-macros would be expressions that have precisely the same behavior as the transformations applied by the compiler including type, value category, whether they are core constant expressions, whether they are potentially throwing, and any others.

@frederick-vs-ja
Copy link

Define a pseudo-macro or pseudo-intrinsic that, [...]

Perhaps this can be editorial?

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