Re: [boost] Boost.Outcome review - First questions

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

Best,
Vicente