Subject: Re: [boost] [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-05-18 21:41:42
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
> 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 believe the
minimal function for recovering an error must be narrow, as you can want
to have the error when you know that there is no value. We could as well
have a wide error function, but I expect his use to be used much less
than the narrow one. The question is, which exception should the wide
error function throw? I've not read the Outcome documentation, but in my
opinion it shouldn't be bad_expected_access.
>> you get a C++ exception thrown of type monad_error(no_state).
> As a side note, it would be nice from my point of view if you
> eradicate these last remaining references to 'monad' in the public
> interface and make that outcome_error (resp. outcome_errc,
>> outcome<Foo> found; // default constructs to empty
>> for(auto &i : container)
>> auto v = something(i); // returns a result<Foo>
>> if(v) // if not errored
>> found = std::move(v); // auto upconverts
I find this 3-state approach more complex than necessary.
> OK, let's go with that. Why not construct 'found' initially to contain
> some error, instead of being empty? You can even define a special errc
> constant to denote an empty outcome.
> Sure, this will not throw the exception in your earlier example which
> accessed v.error() when !v, but is the exception really necessary there?
> What I'm driving at is that these result types are conceptually (T|E)
> and the empty state could just be a special case of E.
> Or, in more general terms, I feel that there's still much extra weight
> that can be stripped off (not in terms of sizeof, but in terms of the
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk