Boost logo

Boost :

Subject: Re: [boost] [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)
From: Peter Dimov (lists_at_[hidden])
Date: 2017-05-14 23:35:08

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

> 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_category.)

> 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
> break;
> }
> }
> if(!found)
> {
> die();
> }

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 interface.)

Boost list run by bdawes at, gregod at, cpdaniel at, john at