On Tuesday, June 23rd, 2026 at 6:04 PM, Ruben Perez via Boost <boost@lists.boost.org> 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.