On Mon, Feb 2, 2026 at 3:52 PM Ion Gaztañaga <igaztanaga@gmail.com> wrote:
Documentation explains what Capy is about (and what the library does not do) but, unless I'm missing something, it does not emphasize why we should use Capy and not any other abstractions (are there are any competing libraries?).
This is a great point and it also highlights a difficulty in proposing such a library. On its own it is difficult to show the value proposition since it is a foundational library. It only solves a subset of user problems and needs things to be built with it to demonstrate utility. A while ago my thinking was to propose the Beast2 family of libraries as a collection. Yet this would be unprecedented in Boost. As we refined the ideas I realized that Capy is the direct analogue of std::execution. That is, it solves the same family of problems that what is about to go into C++26 solves. It also does a little more; things which are specific to I/O expressed in terms of buffers of bytes (the networking use-case). Thus I figure it is probably worthwhile to present these ideas sooner rather than later Maybe reviewers can be more familiar with an example that uses Boost.Asio so that they can compare classic Asio with coroutines vs Capy
(assuming Asio can be made compatible with Capy)?
There has been no effort to preserve any sort of compatibility with Boost.Asio, except for the buffer sequence concepts and that is admittedly such a small aspect that it seems hardly worth mentioning. Asio has its own execution model which is rather constrained. I would suggest that documentation should highlight why Capy
is the way to go.
Yes, I have put together this page to help answer that question: https://master.capy.cpp.al/capy/why-capy.html Thanks