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/