niedz., 28 cze 2026 o 20:39 Vinnie Falco <vinnie.falco@gmail.com> napisał(a):
On Sun, Jun 28, 2026 at 11:25 AM Andrzej Krzemienski <akrzemi1@gmail.com> wrote:
Actually, I do not think I understand this statement. What does it mean when you call the concept `IoAwaitable` a protocol?
A protocol in this context means the type requirements plus the behavioral requirements.
1. What is this concept for? Are programmers/other libraries allowed/expected to provide their own types modelling `IoAwaitable`? Or does anyone is required to only use concrete types that come with Capy?
There are three tiers of users identified in the companion design document
IoAwaitable for Coroutine-Native Byte-Oriented I/O https://isocpp.org/files/papers/P4172R1.pdf
1. Application developers 2. Framework authors 3. I/O library authors
Framework authors and I/O library authors would provide their own types modeling IoAwaitable. Users would simply consume the ones in Capy, or the ones provided by other libraries.
2. If it is the latter, why are we even hearing about this protocol? If it
is the former, then I think the "protocol" is way underspecified.
Capy serves the three audiences described above.
3. I can write my own coroutine return type that has two-argument await_suspend, but lacks await_ready and await_resume. It will pass the IoAwaitable check, but I cannot use it inside a coroutine with capy::task as a return type. Apparently, there are more syntactic requirements here.
The IoAwaitable documentation states:
"An awaitable satisfies IoAwaitable if..."
An IoAwaitable must be an awaitable, which requires at a minimum the three members described.
Term "awaitable" is never defined. Note that with the await_transform magic in place even type `int` can be co_awaited on in some coroutines.
4. And IoAwaitable doesn't mention any semantic requirements. Concepts without semantic requirements are not concepts.
https://develop.capy.cpp.al/capy/reference/boost/capy/IoAwaitable.html#_sema...
My bad.
5. Is it enough for my type to satisfy the concept or is there more that I have to do? How do I make `co_await this_coro::environment` work? Is it even part of the "IoAwaitable protocol"? How is the environment propagated down to other people's coroutines (with their own return types) unless I manually make it work?
"co_await this_coro::environment" is a feature of the task type. It has nothing to do with the IoAwaitable protocol, hence it is silent on it.
So, my type somehow automatically passes the environment down, but my coroutines cannot access it? So how can my coroutines respond to a stop request?
Environments are propagated automatically to any awaitable which implements the IoAwaitable protocol, that's the point of it.
I can see how the environment is propagated *from* Capy types to my types. But I cannot see how my types propagate the environment automatically to other types.
6. What happens with my promise_type's initial_suspend and final_suspend? Are they invoked or overridden by capy::tasks's await_transform?
I believe initial_suspend and final_suspend are invoked directly by the compiler and are not affected (Klemens?)
If so, can I make my coroutines not lazy? That is, not suspend in the initial_suspend point? Regards, &rzej;
I hope that questions demonstrate how unclear it is to the reader what "IoAwaitable protocol" is.
Well... :)
Thanks