Movatterモバイル変換

Suggested resolution:

When a coroutine is invoked, a copy is created for eachcoroutine parameter. Each such copy is an objectorreference with automatic storage durationthatand has the same type as the corresponding parameter.Each copy isdirect-initialized(9.5 [dcl.init])froman lvalue referring to the correspondingparameterif the parameter is an lvalue reference, andfrom an xvalue referring to it otherwise.If thetype of the copy is an rvalue reference type, then for thepurpose of this initialization the value category of thecorresponding parameter is an rvalue. Areferencetouse of a parameter in thefunction-bodyfunction-body ofthe coroutine and in the call to the coroutine promiseconstructor is replaced bya reference to itscopy. The initialization and destruction of each parametercopy...

[Accepted (as paper P2107R0) at the February, 2020 (Prague) meeting.]

(This was previouslyissue 33in the coroutine issue list.)

According to 9.6.4 [dcl.fct.def.coroutine] paragraph 13,

When a coroutine is invoked, a copy is created for eachcoroutine parameter. Each such copy is an object withautomatic storage duration that is direct-initialized froman lvalue referring to the corresponding parameter if theparameter is an lvalue reference, and from an xvaluereferring to it otherwise.

This means that parameters to a coroutine that areconst-qualified will be copy-constructed rather thanmove-constructed. For example, changing the signature ofa coroutine fromtask<void> f(std::string)totask<void>(const std::string) canintroduce an extra string copy and potential heap allocationthat may not be obvious to the author.

It also means that it is not possible to write acoroutine with a const-qualified move-only parameter typelikeconst std::unique_ptr<T>.

The original parameter to the function is generally notobservable to the coroutine body, so there seems to be littlebenefit to preserving the constness of the originalparameter when copying the parameter into the coroutine frame.