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-30 20:12:12

2017-05-30 15:18 GMT+02:00 Niall Douglas via Boost <boost_at_[hidden]>:

> > FWIW, my preferred options would be (which I think were the originals):
> >
> >  - 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?

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

Regards,
&rzej;