Re: [Capy review] Some questions

> > 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.

Thanks.

>
> >
> > 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.

Would it make sense to just use the errc one and remove capy's? Maybe
Peter can suggest something here?

>
> >
> > 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.

It'd help. 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/T7CVNU6CC64T4DL7RNMVEIVT54LFKBWO/