On Mon, Oct 11, 2021 at 9:59 AM KL via Std-Discussion
<std-discussion_at_[hidden]> wrote:
>
> Hello,
> I see many of my algorithms that would take advantage of coroutines to better clarify my code.
>
> I love the simplicity of modern c++.
>
> But at the current state of affairs, I refrain from using coroutines because I feel that it is too verbose, error prone, and globally, a hassle to setup.
>
> As a parallel, I don't need to know how to implement the vector class to use it.
>
> I would like a high level, approachable way to define my function, and use co_xxx inside and be done with it, letting library/compiler to generate a default for me.
>
> Is it the future of the coroutines implementation (easy to use for developers that just want to think about algos running as fast as possible and not the nitty gritty implementation details) or will we be left with a lot of verbosity to make things work?
>
> This is in no way aggressive, I just need to know your point of view.
>
> Thanks

Coroutine functionality is less like `vector` and more like `::new`.
It's *basic* functionality, upon which we build more specific
functionality.

You aren't really expected to hand-roll *every* coroutine management
code you write. You're expected to figure out what your coroutine
usage patterns are and build machinery specific to those needs.

At the present time, there is no generalized "do the thing" for
coroutines, in part because designing what that will look like is very
complex. `vector` is pretty trivial; it's just allocates memory and
moves objects around. But the numbers and use cases for coroutines
(like for memory allocators) are many and varied. It's not clear what
a generalized coroutine system would look like.

There are ideas for what it would look like for asynchronous code, but
even that is delayed due to needing some way of scheduling work. Async
coroutines are based on continuations, and continuations need some way
to schedule work. And the C++ project developing that concept are
"executors".

So until that gets fully sorted out, we can't really move forward with
what a generalized async coroutine system would look like.

Something could be done for generator coroutines, as the main thing
there is making sure that a coroutine generator is also a valid C++20
range. This is pretty well-trodden ground.