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

Subject: Re: [boost] Boost.Outcome review - First questions
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-23 11:47:18

>> At the risk of slightly losing my temper, I need to say something I'll
>> probably regret later when people throw axes at me. But it's been
>> building for a few days now, and I need to vent.
> 
> Usually one hears the complaints much sooner than they hear the praise.

I think the response to my complaint about complaints over
over-engineering was very useful. Some on Reddit foresaw outpourings of
nastiness, and I am pleased to have proven them wrong. I had actually
thought that your opinion of over-engineering was derived from design
choices in Outcome which had nothing to do - at all - with the stuff you
raised which I had thought self evident. So that was great to learn.

But I forget that ABI versioning is new to Boost. libstdc++ has been
doing it for years, and indeed my implementation clones libstdc++'s C++
11 technique very closely. One assumes such features to be completely
uncontroversial, but one is wrong.

> 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:

- Has a gap opened up in C++ between C++ exceptions and return codes
which ought to be filled by something standardardised?

- How important is extensibility in such a solution, and what exact
forms should that extensibility take?

- 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?

- 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?

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

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.

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.

Niall

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