Re: [boost] [review] Review of Outcome (starts Fri-19-May)

Subject: Re: [boost] [review] Review of Outcome (starts Fri-19-May)
From: Peter Dimov (lists_at_[hidden])
Date: 2017-05-18 22:00:20

Vicente J. Botet Escriba wrote:
> Le 15/05/2017 à 01:35, Peter Dimov via Boost a écrit :
> > Niall Douglas wrote:
> >
> >> The major refinement of outcome<T>, result<T> and option<T> over 
> >> expected<T, E> is that you **never** get undefined behaviour when using 
> >> their observers like you do with expected<T, E>. So when you call 
> >> .error() for example, you always get well defined semantics and 
> >> behaviours.
> >
> > I fully agree with this design decision of yours, by the way. In fact I 
> > consider that a defect in expected<>.
>
> Why? We have *e that is narrow and value() that is wide.

I don't like undefined behavior (except when I like it). An accessor that 
gives you the error without checking first would supposedly save a branch, 
which I wouldn't consider an acceptable tradeoff even if it did indeed save 
a branch; but in practice, in correct code the check would already have been 
made and the compiler would be able to see that.

And yes, I don't like *e either.