Re: [Capy review] Some questions

On Tuesday, June 23rd, 2026 at 6:04 PM, Ruben Perez via Boost <[email protected]> wrote:

> 3) Asio has the concept of error dispositions [6]. In a nutshell, these are
> a generalization of error codes, so custom error types can be used in error
> code-aware functionality, like when_any. This is useful in code using
> specialized types. Future candidate Boost.Http uses this in its router [8],
> and I intended to use it as a way to attach error messages in my database
> libraries. I discuss my use case in more detail in this issue [9]. Have you
> considered the feature?

We just haven't gotten to this issue yet. It seems like something we can easily add.

>
> 4) Does capy::cond::canceled add anything vs. just using
> std::errc::operation_canceled?

No, it doesn't. It is there for consistency with our error types that don't have std spellings.

>
> 5) I initially found the when_any semantics confusing. It uses the
> equivalent to Asio's wait_for_one_success semantics [10]. Asio has also
> wait_for_one, and it turns out it's the one I tend to need more. Docs [11]
> propose a workaround - but io_task<std::error_code> doesn't look that good.
> Is there a chance of adding first-class support for this? What is the
> rationale behind making wait_for_one_success semantics the default?
>

We got some early feedback that pointed in the direction that wait_for_one_success would be more widely applicable. There's nothing preventing us from adding wait_for_one as a first class API and it seems reasonable to me.
_______________________________________________
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/GDRSSVDYJK2RZESJNGL6JSZBKR67TOOP/