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 13:11:36

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

> On 31/05/2017 00:43, Gavin Lambert via Boost wrote:
> > On 31/05/2017 01:18, Niall Douglas wrote:
> >> The current behaviour is "always throw on observing empty". That's what
> >> makes empty special (and it traps unintentional propagation of empty).
> >
> > That makes sense when empty is always "you forgot to return a value".
> > However you've said yourself that sometimes you've hijacked it as an
> > intentional return of no value (as in optional<T>), and that's where
> > things get murkier.
>
> You do realise there is nothing stopping a person using the valued state
> to return an error, the errored state to return a value, and the
> excepted state to return a type erased smart pointer?
>

That is of course true, but no-one has ever brought such obviously invalid
(or at least confusing/hackish) use cases.

>
> Empty state is no different.
>

The difference is that you have brought it up as an example of where the
empty state could be used in practice. In the code written by the author of
Boost.Outcome. This is easily taken as usage recommendation.

This is the message I got form reading your replies: It is easy to
implement and use `outcome` without an empty state in the interface, but
without empty state, the use case from AFIO would not work. This is about
the only use case you have shown us.

I am not saying that you have said that explicitly. This is simply my
impression after reading all the posts that mentioned the subject.

>
> >>>   - 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.
> >>
> >> std::make_exception_ptr(std::system_error(error())) is fairly cheap, a
> >> few thousand CPU cycles. std::exception_ptr's are heavy anyway.
> >
> > I can understand that, but I'm not sure I can entirely agree with it. As
> > previously mentioned an error_code return is supposed to indicate a
> > non-exceptional error, while an exception is exceptional.  So this feels
> > like promoting a non-serious error to a serious error.
>
> Sure. But this semantic also means that errors don't get accidentally
> lost if the programmer checks for an exception without checking for an
> error. I figured that to be a safer default.
>

So this is to prevent accidental user bugs? Or rather the consequence of
the mental model where "error" means either error_code or exception_ptr?

Regards,
&rzej;