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/