Apply remaining coroutine TS issues to the working paper.
Proposed change: Apply resolution of the issue 33. “Parameter copy wording does not capture the intent.” from p0664r8.
An identifier is only an id-expression if it has been suitably declared (Clause 9) or if it appears as part of a declarator-id (9.3). [Note: For operator-function-ids, see 12.6; for conversion-function-ids, see 188.8.131.52; for literal-operator-ids, see 12.6.8; for template-ids, see 13.3. A type-name or decltype-specifier prefixed by ~ denotes the destructor of the type so named; see 184.108.40.206. Within the definition of a non-static member function, an identifier that names a non-static member is transformed to a class member access expression (11.4.2). — end note]Change in 9.4.4 [dcl.fct.def.coroutine] paragraph 13:
When a coroutine is invoked, a copy is created for each coroutine parameter.
Each suchcopy is an objectwith automatic storage duration that is direct-initialized from an lvalue referring to the corresponding parameter if the parameter is an lvalue reference, andfrom an xvalue referring to it otherwise. A reference to a parameter in the function-body of the coroutine and in the call to the coroutine promise constructor is replaced by a reference to its copy.The initialization and destruction of each parameter copy occurs in the context of the called coroutine. Initializations of parameter copies are sequenced before the call to the coroutine promise constructor and indeterminately sequenced with respect to each other. The lifetime of parameter copies ends immediately after the lifetime of the coroutine promise object ends. [Note: If a coroutine has a parameter passed by reference, resuming the coroutine after the lifetime of the entity referred to by that parameter has ended is likely to result in undefined behavior. — end note]