Additional note, May, 2021:

Note 7 in 6.9.1 [intro.execution] paragraph 11 refers to evaluations A and B, even though the edit to that paragraph above removes those names. This discrepancy was noticed only after CWG approved the change to the normative wording. Since it involves only the wording of a non-normative note, the problem will be addressed editorially. See editorial issue 4612.

Proposed resolution, May, 2021:

1. Change 6.9.1 [intro.execution] paragraph 11 as follows:

When calling invoking a function (whether or not the function is inline), every value computation and side effect associated with any argument expression, or with and the postfix expression designating the called function, is are sequenced before execution of every expression or statement in the body of the called function. For each function invocation or evaluation of an await-expression F, for every each evaluation A that occurs does not occur within F and every evaluation B that does not occur within F but is evaluated on the same thread and as part of the same signal handler (if any), either A is sequenced before B or B is sequenced before A. is either sequenced before all evaluations that occur within F or sequenced after all evaluations that occur within F; [Footnote: In other words, function executions do not interleave with each other. —end footnote] if F invokes or resumes a coroutine (7.6.2.4 [expr.await]), only evaluations subsequent to the previous suspension (if any) and prior to the next suspension (if any) are considered to occur within F. [Note 7: If A and B would not otherwise be sequenced then they are indeterminately sequenced. —end note]

2. Add the following note at the end of 7.6.2.4 [expr.await] paragraph 5:

The await-expression evaluates the (possibly-converted) o expression and the await-ready expression, then:

• ...

[Note: With respect to sequencing, an await-expression is indivisible (6.9.1 [intro.execution]). —end note]

Drafting note: No change is needed in 6.9.1 [intro.execution] paragraph 8:

...An expression X is said to be sequenced before an expression Y if every value computation and every side effect associated with the expression X is sequenced before every value computation and every side effect associated with the expression Y.

Suggested resolution:

Add the following as a new paragraph following 7.6.2.4 [expr.await] paragraph 5:

With respect to an indeterminately-sequenced function call, the operation of co_await is a single evaluation. [Note: Therefore a function call cannot intervene between the subexpressions constituting evaluation of a co_await expression. —end note]

[Example 1:...

[Accepted as a DR at the June, 2021 meeting.]

The description of co_await should not permit reordering the subexpressions constituting the evaluation of a co_await expression. For example, given

  auto z = co_await coro + co_await coro;

the result may be different from the expected

  auto x = co_await coro;
  auto y = co_await coro;
  auto z = x + y;