Re: [Capy] Review Note

niedz., 28 cze 2026 o 20:39 Vinnie Falco <[email protected]>
napisał(a):

> On Sun, Jun 28, 2026 at 11:25 AM Andrzej Krzemienski <[email protected]>
> 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#_semantic_requirements
>

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
>
>
_______________________________________________
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/5QDNIH76YUJNEIGO7TBHGY2DKCGRADC6/