On Sun, Jul 5, 2026 at 12:31 PM Robert Ramey via Boost < boost@lists.boost.org> wrote:
...we often respond by making a library in spite of this. Things can be made to work. But this ultimately unsatisfactory.
I disagree. I have been working with C++ networking and asynchrony now for over a decade. Capy is hardly unsatisfactory. It is fantastic. Because C++20 coroutines are fantastic. No one knows this, because Certain People Who Shall Not Be Named decided that "coroutines are a poor basis for asynchrony" in just 5 paragraphs of text, with no supporting evidence. No benchmarks. No example programs. Presumably, they saw the requirement for the coroutine frame to be allocated as beneath their design sensibilities and decided it was not worth further inquiry. Guess what? I made further inquiry. C++20 coroutines are great. They are comparable to coroutines in other languages, and of course they have their own particular complexities. But this is because C++ offers its own complexities. Other languages don't give you control over how memory is allocated, or give you pointers, and so on.
I think it's long past time for boost to stop focusing in terms of creating libraries that will one day be added to the standard.
This already happened. Look at the recent libraries that have been added to Boost. Capy and Corosio are no exception. They were not designed to be added to the standard. They were designed to replace Boost.Asio, offering a coroutine-native approach. No more, and no less. It is a happy coincidence that they are also worth standardizing. But let's get the ordering in the causal chain correct: the building of the library for its utility in serving our other high level libraries came first. Thanks