On Thu, Jun 25, 2026, at 3:11 PM, Vinnie Falco via Boost wrote:
On Thu, Jun 25, 2026 at 4:56 AM Rainer Deyke via Boost < boost@lists.boost.org> wrote:
Pretty sure that's not actually true.
Capy provides an execution model for coroutines which offers one simple invariant:
A coroutine will always be resumed by the same Executor object which was used to launch it. [...]
Capy's invariant, stated plainly above, is the coroutine-native expression of the same invariant which Boost.Asio's execution model maintains. Asio's normative requirement, from https://www.boost.org/doc/libs/latest/doc/html/boost_asio/reference/asynchro... :
The completion handler shall be submitted for execution as if by performing dispatch(ex2, std::move(f)).
I do not think that the stated requirements on a completion handler imply the Capy simple invariant as stated plainly. There's *lots* of code out in the wild absolutely relying on the executor being switched from the one returned by `co_await asio::this_coro::executor`: https://godbolt.org/z/r17Kxbrdr which exceed Godbolt limits, but prints: T:01 main enter T:01 now coro on ctxA executor T:02 now on ctxB executor and strand T:01 now back on ctxA T:01 main exit
"Capy vs the entire world of C++ coroutine code" is actually "Capy continues 24 years of proven Boost design, while the rest of the coroutine world chose the path of least resistance."
Looking at the above it would appear Asio has considerably *more flexible* executor semantics around coros. (Side note, I'm not reviewing Capy at this time, just responding to the email I quoted) Regards, Seth