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

Subject: Re: [boost] [review] Review of Outcome (starts Fri-19-May)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-15 21:54:27

>> We don't need to depend on guaranteed return value elision. There is
>> an emplacing constructor, an initializer_list constructor, and the
>> observers return references. So one does not need a default
>> constructor, nor copy nor move.
> 
> How are you going to return it from a function then? That's what these
> types are, function return values.

That's an interesting observation.

Vicente, when he reviewed Outcome's docs, was pretty appalled at how
error handling focused they are. His view is that Expected is an EITHER
monad where E is exactly like T, and he was not happy that Outcome
presents Expected as if it is solely for use for returning stuff from
functions.

And, he is right. Expected has a raft of other uses especially in
functional metaprogramming, and Outcome and its docs does not do justice
to any of those other uses.

But my counter argument is that 70-80% of people out there currently
don't care about those other uses. I know this from having to completely
rewrite the Outcome docs three times. They currently only want to know
about error handling. So I made the docs all about that only.

A non-copyable nor moveable expected<T, E> is no use for returning stuff
from functions, but I can see that such a thing might be useful for
other stuff e.g. a less awkward to use std::variant for some limited set
of variant types. I haven't given it a huge amount of thought yet to be
honest, but the Expected proposal document is very clear that
non-copyable and non-moveable types are permitted.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/