Re: Capy Review

Vinnie Falco via Boost <[email protected]> Fri, 26 Jun 2026 17:05:44 -0700
Newsgroups gmane.comp.lib.boost.devel
Message-ID <CA+EzHGcrPvG5mAFe3qy5M2UbrhVxtEL0aGPPnBtiX2QqE3ZD5A@mail.gmail.com>
On Fri, Jun 26, 2026 at 3:25 PM Rainer Deyke via Boost <
[email protected]> 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.

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

Thanks
_______________________________________________
Boost mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://lists.boost.org/mailman3/lists/boost.lists.boost.org/
Archived at: https://lists.boost.org/archives/list/[email protected]/message/WCSBBJCBVA33XI4BSHOZ6MZRU536JIZ4/