This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 110b. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
[Accepted (as paper P2107R0) at the February, 2020 (Prague) meeting.]
(This was previously issue 33 in the coroutine issue list.)
According to 9.5.4 [dcl.fct.def.coroutine] paragraph 13,
When a coroutine is invoked, a copy is created for each coroutine parameter. Each such copy is an object with automatic storage duration that is direct-initialized from an lvalue referring to the corresponding parameter if the parameter is an lvalue reference, and from an xvalue referring to it otherwise.
This means that parameters to a coroutine that are const-qualified will be copy-constructed rather than move-constructed. For example, changing the signature of a coroutine from task<void> f(std::string) to task<void>(const std::string) can introduce an extra string copy and potential heap allocation that may not be obvious to the author.
It also means that it is not possible to write a coroutine with a const-qualified move-only parameter type like const std::unique_ptr<T>.
The original parameter to the function is generally not observable to the coroutine body, so there seems to be little benefit to preserving the constness of the original parameter when copying the parameter into the coroutine frame.
When a coroutine is invoked, a copy is created for each coroutine parameter. Each such copy is an object with automatic storage duration
thatis direct-initialized from an lvalue referring tothe corresponding parameter if the parameter is an lvalue reference, and from an xvalue referring to it otherwise. A reference toa parameter in the function-bodyof the coroutine and in the call to the coroutine promise constructor is replaced by a reference toits copy. The initialization and destruction of each parameter copy...