There are also two special cases:

/* case 1 */
int fun1(int a = (r.resume(), 0)){
    return a;
}
int v1 = fun1();

/* case 2*/
int fun2(int a){
   return a;
}
int v2 = fun2((r.resume(),0));

First, any function parameter belongs to function parameter scope, thus the variables introduced by parameter-declaration are non-block variables. This proposal intends to use initializer to clarify the issue. However, the clear point in the two cases is that the initializer, in either case, is = E as per the grammar init-declarator (declarator initializer). The subtle point is whether we consider the argument of the call, in either case, as the resumer? Although, the argument is not a grammatical initializer(BTW, the issue regarding the initializer is recorded in #4582 and #4584)

I don't find anything ambiguous. In these two case, the resume calls appear in expressions that initialize other variables, but they are also executed within the initializers of non-block ("global") variables, and outside of functions.

I don't find anything ambiguous. In these two cases, the resume calls appear in expressions that initialize other variables, but they are also executed within the initializers of non-block ("global") variables, and outside of functions.

According to the current proposal, the initializers = fun1() and = fun2((r.resume(),0)) in the two declarations of the global variables are resumers, there are no hazy here. I just wonder Is it possible that the argument that initializes the parameter in the context that is not a block can be a resumer? As exposed by the above cases.

I just wonder Is it possible that the argument that initializes the parameter in the context that is not a block can be a resumer?

I think this is a question of classification. When the resume function is called within another function, the existing wording doesn't treat any smaller structure (e.g. a expression statement) in that function as a resumer.
So IMO an expression in the initializer of a parameter should not be treated as a resumer. The resumer in this case should be one of these two enclosing contexts.

So IMO an expression in the initializer of a parameter should not be treated as a resumer.

If we do not intend to treat the initializer of the parameter as a resumer, the current proposal should be modified as

The resumer is:

• The function, or
• the initializer of a variable that does not belong to the block or parameter scope,

that invokes a resumption member function.

Note that the variable that belongs to a function parameter scope is also a non-block variable as per [basic.scope.block] p1

A variable that belongs to a block scope is a block variable.

This can work if we clarify the definition of the wording "initializer" after fixing issues #4582 and #4584

I think the clarification of "non-block variable" should be handled in another issue/PR. [basic.start.dynamic] frequently uses the item "non-block variable", this PR just reuses the meaning in that section. I've added a cross reference for this use.

[basic.start.dynamic] explicitly states: a non-block variable with static storage duration. However, we did not add that condition for the non-block variable in this PR.

[basic.start.dynamic] explicitly states: a non-block variable with static storage duration. However, we did not add that condition for the non-block variable in this PR.

Thanks. It was my oversight.
The current working draft almost always combines "non-block variable" with "with static (or thread) storage duration", and never uses the item to denote a function parameter. I should follow this (perhaps slightly redundant) pattern.

@GorNishanov, @lewissbaker could you kindly take a look?

I am wondering if there is a more general wording than trying to enumerate all contexts that may resume the coroutine.

I'm wondering whether this should go through CWG. Maybe we can just say "context" instead of "function or x or y or z" instead.

@jensmaurer I would welcome that.

I am wondering if there is a more general wording than trying to enumerate all contexts that may resume the coroutine.

I think we are just trying to say that when a coroutine suspends we return from the call to coroutine_handle::resume() that resumed the coroutine.

So can we say something along the following lines?:

The coroutine resumer is the call-site of the call to coroutine_handle::resume() that resumed the coroutine.

I made CWG2613 for this. Better get larger buy-in for whatever term we end up using.

I'm closing this pull-request; it's unlikely the core issue resolution will use exactly the phrasing proposed here.