Andrzej Krzemienski wrote:
sob., 27 cze 2026 o 16:58 Vinnie Falco <vinnie.falco@gmail.com> napisał(a):
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
sob., 27 cze 2026 o 17:15 Peter Dimov via Boost <boost@lists.boost.org> napisał(a):
It's more than two parts. The second part is actually
1. Buffer sequences
* ConstBufferSequence, MutableBufferSequence concepts * supporting primitives: buffer_begin, buffer_end, buffer_size, buffer_length, buffer_slice
2. Streams, stream-related algorithms
* read, write
3. Type erasure
4. DynamicBuffer
Here (1) has nothing to do with coroutines and is completely independent.
A number of division possibilities, I see. However, if it is really the goal to establish a "bridge component" between different awaitable-style coroutine libraries, then coupling it with another library (which is a bridge between different I/O libraries) reduces the chances of success, as we have already seen during this review.
Both coroutine support and buffer sequence manipulation are foundational for Corosio (and it's not really possible to omit either), so for me both clearly belong in Capy. Streams (and the read/write algorithms) are theoretically possible to omit, but doing so will be a disservice to users and if we do that, it will very likely lead to pressure to add read/write as socket methods.