On Wed, Sep 9, 2026 at 5:16 PM Jeff Garland via Boost <boost@lists.boost.org> wrote:
Understood -- but this is a blocker for myself and at least one other reviewer. I *should* be able to write a service or a tool which is coroutine based and has cancelation without having to pull in all of Corosio. I see that as a pretty basic issue that means Capy doesn't have much future by itself.
There is some loose terminology here which needs tightening. "Cancelation" is a cross-cutting concern. Capy provides the API for canceling things, but it is up to the asynchronous operation to wire it in. Practically, this means supporting std::stop_token (which Capy uses as its low-level primitive). Capy very much has a future, on its own. There are already external users. And the entire [not-yet-proposed-for] Boost.Http library is built on Capy, not Corosio: https://github.com/cppalliance/http/tree/develop/include/boost/http Everything you see in Http, the server, the serialization, the parsing, the algorithms - all written for Capy and not Corosio. Unlike Beast, our new protocol offerings are *high level*. What we are doing is taking the best components from other languages and porting them to idiomatic C++. For example in Node.JS you deliver a complete static website using the serve_static npm module: https://www.npmjs.com/package/serve-static In [not-yet-proposed-for] Boost.Http, this is accomplished with the serve_static class: https://github.com/cppalliance/http/blob/develop/include/boost/http/server/s... Point serve_static at any directory and it will serve it over Http. No Corosio. Only Capy. Still think Capy has no future? :) Welcome to the type-erasure of C++20 coroutines. Boost gets it first, thanks to you Jeff. The paper that explains it all: *What C++20 Coroutines Already Buy The Standard* https://isocpp.org/files/papers/P4088R1.pdf Best