1. The library is not available to C++11 users. I understand that technically this is not against "the rules" but my rationale is as follows:
Firstly, Boost admission requirements are merely that it conforms to the latest published ISO C++ standard. That's currently C++ 17. It's certainly not grounds for a rejection, unless you don't care about the Boost admission requirements.
a. Outcome provides fundamental vocabulary types. Boost has traditionally been the library collection to provide up and coming C++ features. For example boost::variant is usable in C++11 while std::variant is not
If anything, this is an argument in favour of it being written in C++ 17, even C++ 20.
b. Nothing in the implementation of Outcome should require C++14. As an example, Peter wrote a remarkably good version of expected and result using only C++11 and his "better variant" class (which also only requires C++11). Unfortunately he never published this work. I would prefer it over this Outcome.
I think you'd be surprised at the number of internal compiler errors in older compilers when using anything Outcome-like of STL implementation quality in big codebases, maybe Peter will confirm. Outcome v1 went out of its way to support old compilers right back to clang 3.1 and GCC 4.9, it had many workarounds to suppress ICEs. It also used preprocessor metaprogramming to avoid pushing too hard on compile-time selected CRTP, because that ICEs older compilers and it's also hard on compile time. The last peer review was really clear that the preprocessor metaprogramming had to go. I did warn at the time that you'd get an equivalent structure in templates with all the consequences thereof, but people still wanted the preprocessor work gone. So it's gone. But the price is the compiler requirements, which are now high, because compilers just weren't reliably up to it until recently. Most of the complaints I've received so far from various users is about the high compiler version. Nobody is too bothered about the C++ 14, it's rather that the C++ 14 compiler that they will be using next few years is not as new as GCC 6 or VS2017. That's a far bigger problem for end users.
c. As Beast is C++11 and relies heavily on error_code, I can't use it in Beast.
That is however your choice Vinnie. C++ 14 is a bug fix release of C++
11. I don't know why you'd not want to move to a standard with so many
bug fixes. Most of your user base has moved, or will soon, for that very
reason.
But maybe I can do something for you anyway. After failing to persuade
boost-dev to substantially modify Boost.System, over at SG14 we are
discussing a
2. The source code is generated from another project with a different license.
I own almost all the copyright. I can license my work under any licence I like, including multiple licences under the Geneva Copyright Convention which is an international law. This is a non issue.
3. The Boost policy gives library authors practically unlimited discretion to make any changes they want after their library has been accepted. I have seen endless public examples where the author quarrels with other developers. I am concerned that after acceptance, Outcome will generate significant conflict over the odd choices which the author will unquestionably make and implement (as evidence by the odd choices the author has made in the past).
a.k.a. you don't like me, so no Boost for you. Ok.
4. This library is too complicated for what it does: policies are unnecessary.
Corporate users are very enthusiastic about the policies because it lets
the leadership programmers impose consistent and totally bespoke rules
across the entire codebase upon all the other programmers. Until now,
macros were the main tool for this. It's a big gain for them.
Now, me personally, I've never actually used a custom policy yet in any
of my own code. But it's going to come in real handy with the proposed
SG14
I recognize that some of these reasons may be considered outside the scope of the review process (for example, considering the qualities of the author in addition to the library). I think they are relevant.
The only requirement regarding qualities of the author is "The author must be willing to participate in discussions on the mailing list, and to refine the library accordingly." I've spent four years bringing this library to Boost, and did a complete rewrite because Boost asked for it last year, including taking a big risk on test casing new tooling for documentation because so many people dislike doxygen as we saw last peer review. I've been involved with Boost since 2002, and I've been here on boost-dev since 2012. I've served Boost in many capacities over the years, including spending quite a bit of their money. Not to blow one's own trumpet, but there are only a few library authors still here with a similar record of longevity and service to Boost. Up to you how you feel my qualities are, but I suspect your opinion is emotionally not factually based.
This review is late for a number of reasons. Among which: I was expecting a significant number of people to reject it. At the very least, the people who rejected the last submission. And I realize that my review will cause a significant amount of drama on its own, which I hoped to avoid, by the frank and somewhat confrontational nature of it.
You're grinding your axe. I suppose you feel entitled to do so after I publicly chided you on what an opportunity you missed on how you ran the Beast review. You just wanted into Boost no matter how. So fair enough. But perhaps you should look instead at how Outcome was done: I took the (very) long way round on getting this library into Boost, and now Expected/Outcome is considered so boring and "done" by the C++ community that none of the reviews questioned any of the major design decisions. There's widespread buy-in to this design, and I look forward to seeing how WG21 reacts (not well, I am sure). Reviews instead almost entirely focused on nitty gritty details like commas and spelling and what HTML theme to put on the documentation. I consider that a big success, we as a C++ community came together and collaboratively decided on an ideal form for a C++ `Result<T>`. Cool. That's what you can get if you run a Boost review right. Thanks for the review Vinnie. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/