cplusplus / CWG

Core Working Group
24 stars 7 forks source link

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

Open ericniebler opened 1 year ago

ericniebler commented 1 year ago

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 commented 1 month ago

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

Perhaps this can be editorial?