On Mon, Jun 29, 2026 at 12:53 PM Vinnie Falco <vinnie.falco@gmail.com> wrote:
On Mon, Jun 29, 2026 at 12:36 PM Ian Petersen via Boost < boost@lists.boost.org> wrote:
We already have std::execution::get_stop_token and std::execution::get_scheduler (which are analogous to but different from the stop token and executor members in the proposed IoAwaitable); my own paper, P4223, directly inspired by Vinnie et al's work on Capy, proposes std::execution::get_frame_allocator. I suspect that the interop problem would be greatly ameliorated if Capy made use of the existing, standard context-sharing protocol, no?
First welcome to the Boost Formal Review of Capy and Corosio :) Thanks for visiting.
Thank you :)
Now, does P2300 define any awaitable types?
If I've followed the discussion on Capy properly, I think Capy and P2300 define roughly the same number of awaitable types. I don't know what the number of awaitable types in P2300 has to do with whether or not Capy ought to reuse its standard context-sharing protocol, though. Ian