On 6/27/26 02:05, Vinnie Falco via Boost wrote:
On Fri, Jun 26, 2026 at 3:25 PM Rainer Deyke via Boost < boost@lists.boost.org> wrote:
I'm fine with 'co_await foreign_awaitable(awaitable)'
Let's unpack this. You want:
co_await universal_bridge( other_coro() );
You say you want to call this from inside a Capy coroutine. The desire is understandable yet there is an asymmetry here.
How can universal_bridge() possibly work when other_coro() returns an IoAwaitable?
Answer: it can't.
universal_bridge() is impossible to implement universally. It is a one-way door. Capy can consume the world, but the world can't consume Capy, unless the world learns the IoAwaitable protocol. Which means every library needs a Capy-specific adapter. Which means N libraries need N adapters. Which means it doesn't scale the way you want.
Yes, that's the problem I pointed out. N libraries, each requiring N - 1 adapters, where N is constantly growing. This is not sustainable. Capy must either step up as *the* universal coroutine library, or it must vanish entirely. Anything between these two extremes leads to madness.
The real solution is: everyone agrees on a protocol for propagating executor + stop token + allocator. Then one bridge covers everyone. That is IoAwaitable. Or, more poignantly:
std::io_awaitable
And that's the solution I'm looking for. But I'm told this is outside the scope of Capy, which should only be used for socket-based i/o using corosio. (Although I wish you'd replace the "io" part of the name, because the goal is a universal system, not one linked to i/o. Corosio notwithstanding, there is nothing inherent about IoAwaitable that makes it more applicable to i/o tasks than any other coroutine task - and if there were such a shortcoming, it should be fixed.) -- Rainer Deyke - rainerd@eldwood.com