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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk