Re: [boost] [outcome] High level summary of review feedback accepted so far

Subject: Re: [boost] [outcome] High level summary of review feedback accepted so far
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-05-31 11:02:11

2017-05-31 12:47 GMT+02:00 Niall Douglas via Boost <boost_at_[hidden]>:

> On 30/05/2017 21:12, Andrzej Krzemienski via Boost wrote:
> > 2017-05-30 15:18 GMT+02:00 Niall Douglas via Boost <
> boost_at_[hidden]>:
> >>>  - value() throws if holding error or exception (or empty)
> >>>
> >>>  - error() returns E{} if holding value or E{errc::has_exception} if
> >>> holding exception, or E{errc::no_value} if empty (names made up on the
> >>> spot, doesn't matter)
> >>
> >> The current behaviour is "always throw on observing empty". That's what
> >> makes empty special (and it traps unintentional propagation of empty).
> >>
> >>>  - exception() returns nullptr if holding value or error or empty
> >>
> >> The current behaviour is to return null exception_ptr if valued (so
> >> if(eptr) would be false i.e. "no exception here"),
> >> std::make_exception_ptr(std::system_error(error())) if errored, throw
> on
> >> empty.
> >>
> >> So an errored state is also an excepted state, but an excepted state is
> >> never an errored state. has_exception() returns true for either errored
> >> or excepted states.
> >>
> >
> > But is there some mental model behind this decision?
>
> Of course.
>
> exception <= error < value. So errors are exceptions, but exceptions are
> not errors.
>

I still don't get it. Maybe what you are saying that "error" refers to both
error_codes and exception_ptr-s, whereas "exception" refers to
exception_ptr-s exclusively?

> empty is the wildcard. It is modelled like NaN in floating-point, it
> propagates in a dominant fashion unless you explicitly deal with it.
>
> >> std::make_exception_ptr(std::system_error(error())) is fairly cheap, a
> >> few thousand CPU cycles. std::exception_ptr's are heavy anyway.
> >
> > Or are these decisions, what to return in tricky cases are only driven by
> > performance?
>
> If you are using result<T> instead of outcome<T>, it is assumed that you
> must feel an exception_ptr to be too expensive and/or you are not using
> exceptions at all. outcome<T> implicitly converts from result<T> on
> demand, so some code you can write without exception_ptr, some with, and
> the two interoperate seamlessly by all funnelling into outcome<T>.
>

Yes, this has always been clear from the docs.

Regards,
&rzej;