Re: Capy Review

Rainer Deyke via Boost <[email protected]> Sat, 27 Jun 2026 09:33:40 +0200
Newsgroups gmane.comp.lib.boost.devel
Message-ID <[email protected]>
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 - [email protected]

_______________________________________________
Boost mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://lists.boost.org/mailman3/lists/boost.lists.boost.org/
Archived at: https://lists.boost.org/archives/list/[email protected]/message/IXDUAFZJHHBRTULS3RNIVFIVJHDOV44F/