Capy types need renaming #395

Activity

1. github-project-automation

   added this to Beast2on Aug 31, 2026
2. github-project-automation

   moved this to Backlog in Beast2on Aug 31, 2026
3. akrzemi1 commented on Aug 31, 2026

   

   akrzemi1

   on Aug 31, 2026

   Contributor

   More actions

   I do not know why, but while I do not mind reusing popular names like task in namespace capy, I feel uncomfortable with capy::result and it having a quite opposite meaning to boost::result.
4. gubnik commented on Aug 31, 2026

   

   gubnik

   on Aug 31, 2026

   Last edited by gubnik

   More actions

   ExecAwaitable feels like the most explicit name to highlight the idea of inherent executor affinity built into the protocol. EnvAwaitable and EnvAwareAwaitable are also a bit confusing in light of std::execution::task<T, Environment> as per P3552. If (or rather when) std:execution model becomes common it would be confusing to have EnvAwareAwaitable that isn't related to std::execution environment. capy::env is fine because it is not something an unprepared user would normally encounter unless they implement an awaiitable of their own, which forces them to get acquainted with Capy's protocol anyway.

   I agree with Andrzej on capy::result. It says nothing about the nature of what the user is working with, and to add insult to injury it collides with boost::result and all the other result people write. I would prefer something more explicit, for example capy::partial. I am not proposing this specifically but it indicates what the user is dealing with better than just capy::result.

   👍React with 👍1Reacted by Steve Gerbino
5. akrzemi1 commented on Aug 31, 2026

   

   akrzemi1

   on Aug 31, 2026

   Contributor

   More actions

   capy::env is fine because it is not something an unprepared user would normally encounter

   IoAwaitable or its rename is also something normal people will never encouter. They will only be exposed to task<> or most of the time. Even though the docs and the papers keep using the name, user programes will not see it.

   Back to result, let me share another observation. The type tuple<error_code, ...> is actually specific to an operation on a single stream. These stream operations will consume/fill a portion of the buffer, always return "what adventures happened to the stream" and often the size, which can be zero. And as long as you are operating on a single stream, you do not have to distinguish between "result from the stream" from "avoid exceptions". But the moment you do something more complicated, a simple tuple no longer serves the purpose of "avoid exceptions". For more complicated types that one would want to return, like we face now in Bost.HTTP, you now need a variant<error_code, T>. The famous push_to/pull_from operations that operate on two streams suddenly need statuses of two streams to be reported.

   Long story short, @gubnik's capy::partial is quite good. Other candidates: stream_result<...>.
6. gubnik commented on Aug 31, 2026

   

   gubnik

   on Aug 31, 2026

   Last edited by gubnik

   More actions

   IoAwaitable or its rename is also something normal people will never encouter

   You are right, yes. I was thinking about a potential API outside of Capy which could use an IoAwaitable but that's highly unlikely now that I try to actually think of one.
7. klemens-morgenstern commented on Aug 31, 2026

   

   klemens-morgenstern

   on Aug 31, 2026

   Contributor

   More actions

   • capy::env is good.
   • capy::io_result - I don't know why we need io_result at all, just use a tuple. I want to tie my ecs.
   • capy::task - yes, in theory we could do the same for io_awaitable.

   Ok, let's bikeshed io_awaitable: maybe some obscure name is better, something that screams at you?

   awaitable is an alright name for a concept, in the same way that drivable would make sense as a concept for my car.
   However, I don't think we need to strictly use nouns for concepts, this read just fine to me: template<can_drive Car>.

   IoAwaitable is bad because it sounds like something that can await io. It's like saying RoadDrivable but including dirtbikes.

   What it actually means is: an awaitable that accepts an environment; we could either just make that implicit and go for capy::awaitable, because that is what is awaitable in the context/environment of capy. Or we find a way to express the env awareness - e.g. groundedAwaitable. env_awaitable sounds like it's awaiting the environment.
8. akrzemi1 commented on Sep 1, 2026

   

   akrzemi1

   on Sep 1, 2026

   Contributor

   More actions

   [...] Or we find a way to express the env awareness - e.g. groundedAwaitable. env_awaitable sounds like it's awaiting the environment.

   Looks like EnvAwareAwaitable satisfies your criteria.

   I would also like to add another name to the bikeshedding exercise. The docs use in a lot of places the term IoAwaitable-protocol. We do not need to use the concept name (whatever name we settle on) while describing the protocol. We could use "environment-propagation-protocol".
9. anarthal commented on Sep 1, 2026

   

   anarthal

   on Sep 1, 2026

   More actions

   I like capy::env. I don't like capy::partial at all - that'd mean Corosio's resolver returns capy::partial<resolver_results>. I'd consider dropping the alias. capy::result kind conflicts with system::result, but if the alias is to be kept, I'd be ok with it.

   I'm ok with task defaulting to todays io_task if you rename the base template to basic_task.

   EnvAwaitable looks like the most explicit to me.
10. sgerbino commented on Sep 1, 2026

    

    sgerbino

    on Sep 1, 2026

    Last edited by sgerbino

    CollaboratorAuthor

    More actions

    • capy::io_result - I don't know why we need io_result at all, just use a tuple. I want to tie my ecs.

    I will just bring to your attention that it is a tuple, it is just an alias now. Maybe your suggestion is just to remove the alias?

    👍React with 👍1Reacted by Klemens Morgenstern
11. sgerbino commented on Sep 3, 2026

    

    sgerbino

    on Sep 3, 2026

    Last edited by sgerbino

    CollaboratorAuthor

    More actions

    Updating this issue to the latest discussions on slack.

    IoAwaitable —> ContextAwaitable
    IoAwaitableRange —> ContextAwaitableRange
    IoRunnable —> ContextRunnable
    io_result — Remove the alias std::tuple< std::error_code, ... >
    io_task — Remove the alias task< std::tuple< std::error_code, ... > >
    io_env — await_context
    io_awaitable_promise_base — context_awaitable_promise_base
12. sgerbino

    added a parent issue on Sep 10, 2026

    • Boost review: acceptance conditions and follow-up tracker #416
13. akrzemi1 commented on Sep 12, 2026

    

    akrzemi1

    on Sep 12, 2026

    Contributor

    More actions

    While at harmonizing names, I suggest that the naming around this_coro be reconsidered. Looks like today the only usage for this namespace is to access the data previously passed via io_env (which now may become await_context). Do we envision getting other things va this mechanism (like getting direct access to the promise object)?

    Because these "tags" could be shorter and have names corresponding to those used when passing the context:

    co_await get_await_context;
    co_await get_await_context::allocator;
    co_await get_await_context::executor;
    co_await get_await_context::stop_token;
14. cppalliance

    locked and limited conversation to collaborators on Oct 1, 2026
15. sgerbino

    converted this issue into a discussion #440 on Oct 1, 2026