Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

Subject: Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2018-01-31 00:09:15

> 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 <system_error> replacement which solves all the major
problems that SG14 has with error_code. It closes some of the gap with
Outcome deliberately, and may be a useful stand in for C++ 11 users with
legacy code bases based on error_code, or which don't need or are
unwilling to use Outcome.

I think it too small a library to go into Boost alone, so I may just
implement it into Outcome as an optional, and usable standalone to C++
11, extension. We'll see how things go, it's very early days right now.

> 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 <system_error> replacement, just a few typedefs and we're done,
there is complete integration of the SG14 replacement and Outcome. Which
is pretty cool.

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