On 6/27/26 04:49, Peter Dimov via Boost wrote:
Rainer Deyke wrote:
On 6/27/26 02:05, Vinnie Falco via Boost wrote:
The real solution is: everyone agrees on a protocol for propagating executor + stop token + allocator. Then one bridge covers everyone. That is IoAwaitable. Or, more poignantly:
std::io_awaitable
And that's the solution I'm looking for. But I'm told this is outside the scope of Capy, which should only be used for socket-based i/o using corosio.
This has to be a misunderstanding. Establishing this protocol and testing it in practice was definitely a goal for Capy, and the most important one (for me at least.)
I am referring back to this:
So that we don't waste everyone's time (including mine), Capy and Corosio are a replacement for Boost.Asio. That is the stated intent.
And this:
A review that evaluates only Capy, declines to examine Corosio, and finds it wanting is not engaging with what was submitted. I wouldn't call such a review an abomination. I would call it a misunderstanding.
Look, Capy is either the coroutine library to end all other coroutine libraries, the future of how coroutines be written in C++, proposed as *the* set of coroutine types and concepts in the standard library - or it's the non-socket layer of a specific socket i/o library. It can be one or the other, but it cannot be both. And it looks like the authors of Capy, collectively speaking, have not made up their mind about which one it is. So far, I have reviewed Capy as if it was the former, and was told it was the latter. But when I actually engage with it as if were the latter, I get told that it's the former. I realize that there are multiple different people with different opinions behind Capy, and that individual people can change their mind, but from the outside this looks like evasion. Any criticism can be dismissed by redefining the scope of Capy on the spot. You people need to get your act together and decide what the scope of Capy really is. For the record, I think Capy the universal coroutine library has a future, although it definitely wasn't ready for inclusion in Boost at the time I reviewed it and I'm not sure it is now - and I think that Capy the socketless socket i/o library layer does not. The former is a standardized set of wheels that everyone can use, the latter is an invitation for every library that uses coroutines to reinvent the wheel. -- Rainer Deyke - rainerd@eldwood.com