On Tue, Feb 17, 2026 at 5:46 AM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
Should the reviewers pay equal attention to both libraries or just one of them?
Great question, and the short answer is: both of them. In practical terms, a user of Corosio who wishes to deploy the library to maximum effect will want to structure their code into two parts: * Algorithms which use Corosio directly: resolving domain names, connecting to the network, configuring TLS * Generic algorithms which operate on Capy byte streams: parsing, serialization, using combinators (when_any, when_all) 1. The user authors Corosio algorithms as coroutines returning `capy::task` 2. The user type-erases Corosio sockets using `capy::any_stream` 3. The user performs reading and writing on Corosio I/O objects, yet the buffer sequence concepts and algorithms come from Capy. The reason for this split is structural: each library exposes a narrow interface over a deep modul with non-overlapping responsibilities. This is explained at length here: https://develop.capy.cpp.al/capy/8.design/8b.Separation.html "Capy and Corosio sit at different levels of the physical hierarchy. They encapsulate different information, change for different reasons, and have different platform dependencies. Merging them would degrade the design along every axis that matters for a large-scale system: testability, reusability, and build cost." More evidence of the utility of this split, is that the facilities in std::execution strongly mirror those in Capy. Yet Capy is directed towards users of regular C++, while std::execution is directed towards users of the Sender Sub-Language. Boost.Http (not proposed yet) is implemented entirely in terms of Capy. It is already capable of doing more than Boost.Beast yet depends on a dramatically reduced API surface. This is evidence that the split is the right choice. Originally I hoped to submit Capy independently yet Peter as usual succinctly observed: users cannot value a solution to a problem they do not yet have. Without a use-case the utility of Capy is invisible. It became evident in this thread: no endorsements were forthcoming until a user appeared (Boost.Redis port, which used Corosio). I explore the phenomenon Peter described in greater depth here: https://www.vinniefalco.com/p/the-expertise-gap Thanks