Re: [boost.async] Seeking Endorsement

From: Christian Mazakas (christian.mazakas_at_[hidden])
Date: 2023-07-25 18:31:57

> Not if we want users. Coroutines ate much more relevant at this time.

The problem is, this definitely isn't true.

Users already have Asio's `use_awaitable`. A coroutine library that uses
Asio as its event loop is basically a lateral move from, well, just using Asio
with `co_spawn` and `use_awaitable`.

Not like I wanna veer off too far into the weeds here about Requests
vs whatever.
But I really don't think coroutines are much more relevant than a
robust HTTP client
that's written using Asio's coroutines today.

But I feel like I have a better understanding of the library now and its goals.

> And it'll provide functionality that should be in the standard, just
> like boost did before 2011.

The problem is, this also isn't true.

This kind of functionality should never touch the standard because it
ties a coroutine
to an execution context. In fact, I'd argue this library's biggest
mistake is doing exactly that.

What I'm thinking of is something like cppcoro's task type, a task
type that can only be co_await'd
by a parent coroutine. To this end, `cppcoro::task<T>` can appear in
interfaces and then runtime
authors are free to invoke this via their own runtime-specific
coroutine types. cppcoro's task stores
the type-erased coroutine_handle when it's transformed into an
awaitable so it works with all
parent coroutine types.

I think we need vocabulary types like that, with schedulers set
alongside them. It worries me to see
an executor directly tied to a coroutine when it's really not
required, let alone purported that this
should actually be a standardized practice. There's definitely room
for innovation in the coroutine
space but it's hard to argue for a "coroutine library" that I can't
even use without bringing in Asio.

- Christian