On Sat, Jun 27, 2026 at 7:29 AM Andrzej Krzemienski <akrzemi1@gmail.com> wrote:
So, you want just the Awaitables protocol? Use a subset of Capy. You want an ASIO replacement? Use Capy + Corosio.
Right
Maybe Awaitables should be its own library?
The include are structured that way, to some extent, through the subdirectories in include/boost/capy. However this point to a tension in the Boost. There are competing forces: * Users want as few dependencies as possible * Users also don't like the monolithic distribution * Good engineering means decomposition of concerns, but * each library has to pass a review For the last point above, note that even though Corosio and Capy were presented as a bundle, Capy was evaluated independently, and the Capy portion was rejected by one reviewer. In practical terms the more finely decomposed an offering into individual libraries, the harder it is to present and pass review.
If not, maybe at least have the documentation in Capy split into two distinct sections, and not mix them in the Reference section.
Documentation can always be improved, yes Thanks