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?
- 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
I believe the monadic stuff found in other functional languages (math) is a good base for the design. 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