Boost logo

Boost :

Subject: Re: [boost] Boost.Outcome review - First questions
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-05-23 18:58:48

Le 23/05/2017 à 13:47, Niall Douglas via Boost a écrit :
>> On a positive note, there is considerable effort evident in Boost.Outcome.
>> It solves a problem worth solving and reflects attention to details. Thank
>> you for investing the time to develop this library and put it through the
>> formal review process.
> What drove me to invest the last six months of effort to turn Outcome
> from an open source library into a Boost candidate library was
> particularly to seek feedback on what is a wide and general topic
> affecting the future of C++ in general, hence the vitality of this
> review compared to most recent Boost library reviews:
I profit to recall that TBoost.Expected started as a not-accepted GSOC
Boost project long time ago (May 2013).

> - Has a gap opened up in C++ between C++ exceptions and return codes
> which ought to be filled by something standardardised?
I believe it.
> - How important is extensibility in such a solution, and what exact
> forms should that extensibility take?
We don't know never what the user will have as errors, so I believe the
mechanism must be extensible.
> - Should a solution be layers of increasing sophistication (class
> hierarchies), connected islands of individual implementation (Vicente's
> plan), one framework to rule them all (most open source C++ monadic
> programming solutions), single implementation/multiple personality (my
> design choice), or something entirely different again?
I believe the monadic stuff found in other functional languages (math)
is a good base for the design.
> - What tradeoff is appropriate between extra typing of boilerplate so
> programmers must spell out what they mean versus imposing a steeper
> learning curve on programmers to understand the primitives they are using?
I believe that a lot of programmers are already the monadic approach
without knowing they are using it in languages as Python. They just use
the design they see in others examples.
Once we will have such interface in C++ (on boost or on the standard) we
will start to see people to use it in a natural way.
> - How will choices made here and now benefit or damage all future C++
> code? Will we in ten years look back and really wish this library and
> the entire philosophy of monadic return types had been rejected?
Just a remark. Even if std::ex...::expected,std::optional and
boost::outcome can be monads, there is nothing monadic until we
introduce the monad::bind/chain or monad::unwrap/flatten functions?
Your TRY macro play the role of the do-notation, but it works only for
PossiblyValued types which std::ex...::expected,std::optional and
boost::outcome are. There are other Monads (e.g. list) that will not
work with the TRY macro.
> Vicente has been very honest in saying here he isn't sure on any of
> this, and I echo the same sentiment: I'm not sure either. Outcome's
> design choice, even after this much review so far, I still feel to be
> the least worst of those I am aware are available, but be clear that
> none of the design approaches is without problems.
I agree with this last sentiment.
> So I totally get that
> others will disagree with the design choice, they feel they'd do it
> different, and I would be fairly sure that their totally different
> designs would probably be just fine as mine as far as end users are
> concerned.
User interface is important as well as how it can be configured (if
needed at all).
Changing the interface changes the user appreciation. I believe that
before the implementation we are discussing here mainly of the user
> After all, what is the end user experience with Outcome? 95% won't care
> how it's implemented. They care about the cost to try it out, whether
> locking into this dependency will later turn out to be costly, whether
> the documentation is useful, and probably in that order. How stuff works
> under the bonnet doesn't matter so long as it doesn't bite them in the
> ass down the line in some particularly costly and unpredictable fashion.
I don't care too much of the implementation as soon as I don't pay for
what I don't use, and the implementation is not guiding the interface.
However in a Boost review the implementation is also important, even if
I take it after the interface, the design and the documentation.
> It's why I was persuaded by Reddit to drop documenting how to extend
> Outcome with your own custom personalities. It's fairly self evident
> from the (well commented) source code anyway for the < 5% who would ever
> be interested. I didn't go mad and choose some weird approach, the
> policy based design is 100% standard, conventional, layered CRTP. Any
> Boost dev should find extending easy.
We are reviewing the library. If one of the major interest is that the
library is configurable, the extension mechanism should be documented in
order to be reviewed.


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