On Tue, Jul 7, 2026 at 2:39 PM Alan de Freitas via Boost < boost@lists.boost.org> wrote:
I think the split into two libraries here is also a little controversial and not well articulated
Yes not well articulated. Although there is this: https://develop.capy.cpp.al/capy/9.design/9b.Separation.html
My impression is that the decision was based on conditions that no longer apply (probably something about dependencies),
Not correct. Capy provides the coroutine foundation and abstract byte-oriented streams. You can implement quite a lot with just this, without Corosio. And people have done so.
Splitting functionality also doesn’t make much sense here in my opinion, because (i) Capy is intended to be used only with Corosio
I think this was the misunderstanding. My fault for the miscommunication. Capy has value beyond just Corosio, people are already building on it.
Corosio shouldn’t be used to justify missing features to people who request them
Here I disagree. As Peter said, Capy is supposed to have the absolute minimum. It should be difficult to add things to the library. I mostly agree. I prefer to ship small and add later as evidence of need becomes available. And even then, start by offering examples which can be used and tested, before promoting them to official public APIs with the promise of eternal backward compatibility.
and the documentation should explain the explicit decision from the very beginning.
Yes see above.
it seems like the argument for the split keeps moving the goalposts
Nope, goalposts are not "keeps moving." They moved once, my fault for the miscommunication so I will state it plainly here: Capy has value on its own, people are already building on it. Thank you for participating in the review Regards