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-18 14:52:26

> It's interesting. Only after Peter's explanation I am able to see the
> usefulness of outcome<>, at least this part of the interface. It looks like
> you - Peter - have the understanding of Niall's intentions. And I am
> clearly lacking them. I would not be able to figure out this use case from
> the tutorials of the reference.
> 
> This gives me the impression that the library has a big potential, but it
> may not succeed because of the failure to explain its power to potential
> users.

This has been a persistent problem over the past year.

Once you've been using these things in your own code for a bit, for
especially low level systems libraries you'd never willingly go back.
The difference is very similar (to me at least) to that feeling you have
when you must go back to writing C++ 98 without Boost after you've been
using C++ 14 for a quite a while.

All that said, 60-70% of C++ would see no benefit to using Outcome nor
Expected. Such code is always better off using only C++ exceptions.

> It would really be helpful to see a section in the docs with a number of
> examples simple as the ones above, explaining different use cases.

I am hesitant to add even more length to the existing documentation.
It's already long enough to put people off.

A refactoring and shortening of the current length would be much more
desirable.

> I am
> still missing how the tribool logic can be used: in if-statements?
> 
> ```
> if (o1 || o2) ... // is that it?
> ```

Outcome provides both binary and ternary conversion operators.
Unqualified usage in an if statement will use the binary edition which
is true iff state is valued, false otherwise. If you compare an outcome
to a tribool, you'll use the ternary edition, there you can test against
true, false, and other.

If ternary logic suits your use case, using it can make your code much
clearer. Other use cases would do better testing .has_value(),
.has_error() and .empty() explicitly. Still other use cases would do
better to dispatch to a function overload based on the current type of
the state.

Niall

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