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