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 09:26:39

>> It's certainly not grounds for a rejection, unless you don't care about
>> the Boost admission requirements.
> 
> "Don't care" is emotionally charged language. And also false. I care
> very much, especially for cases where the Boost admission requirements
> and review process show a weakness.

And yet here you are posting a review mostly made up of emotional
concerns, not technical ones, not engineering ones. And not even factual
ones - my first open source landed on the internet over 25 years ago,
some of which is still actively supported by me. Nobody can claim that I
haven't been at this for a very long time now, and have more than
demonstrated my long term commitment.

> I disagree. As we have seen in the recent survey, C++11 is overwhelmingly
> popular. Your advice to consider C++17 is exactly the type of bad
> decision-making
> that I am concerned about if Outcome is accepted into Boost. To wit, requiring
> C++17 would exclude 88% of potential Boost users. Even requiring C++14
> excludes two-thirds of all C++ programmers. See:

This is such not an issue.

At best, Outcome might land in the Summer release, more likely the
Winter release. That means it doesn't reach end users until 2019, most
of whom only update to a recent Boost every two years or so. So now
we're talking 2021, a time by which C++ 11 users will be a minority.

>> ...But the price is the compiler requirements, which are now
>> high, because compilers just weren't reliably up to it until recently.
> 
> Part of the skill of a Boost C++ engineer is to figure out how to make it
> work on older compilers, without being too taxing on them. We suffer
> so the users don't have to.

Or, in fact the skill of a Boost C++ engineer is to see through
fashionable concerns for what are actual, rather than commonly believed,
engineering exigencies and design a truly correct library rather than
one which ticks all the popular boxes and rouses the rabble.

Anyone wanting to stick to C++ 11 for the next five years is unlikely to
be a risk taker, and thus unlikely to want something like Outcome
anyway. There is also a raft of end users who will be jumping straight
from C++ 03 to C++ 17 because they like to track whatever is the last
point bugfix before a major release (I know I do exactly this myself in
everything from new computers to new cars, it saves such a huge amount
of hassle, and you usually get great end of line discounts. But I digress).

You've got some axe to grind on C++ 11 being far more important for
potential users of Outcome than is actually the case. I don't know why.
Even if it were a problem in 2018 for some kinds of end users who want
Outcome, it definitely is much less of a problem in 2019. I've already
had big corporates reaching out saying they are thinking of folding
Outcome in with their toolchain upgrades in 2019, so the timing for them
is perfect. Fundamental libraries like Outcome are always treated very
conservatively because of the severe lock in and the fact your entire
codebase will be ruined if the fundamental library ends up having a
broken design or its ABI changes, breaking all your prebuilt DLLs.

None of these issues are anything like as pressing with niche libraries
such as Beast. So perhaps you don't get the conservatism at work here.
Few big users will be adopting Outcome quickly, they'll take at least a
year, maybe two. We're talking 2019, 2020 for most big users.

>> But maybe I can do something for you anyway. After failing to persuade
> 
>> 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.
> 
> This is again the questionable decision-making that I am concerned about
> if Outcome is accepted into Boost. I consider adding a substitute for error_code
> to be outside the scope of the library. Such an addition should be in its own
> library and get its own review. You are effectively stating that you do not
> believe your idea has enough merit to survive a review, so you will simply
> add it to your already-published library.

I love how you read in whatever emotional interpretation you wish to
twist in irrespective of facts.

Firstly, said micro-library - and it's two classes, so it's a
micro-library - is purely an experimental and optional extension. It
won't be used by default, which will remain std::error_code.

Secondly said micro-library is hardly being invented out of nothing. It
addresses the consensus issues raised in https://wg21.link/P0824.

Thirdly, who said it would not be reviewed here? You did, without
evidence. It'll definitely pass before here for feedback before I start
work on a proper implementation. Firstly I need to merge the substantial
feedback from SG14, and get sign off from there.

>> 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.
> 
> The problem comes when someone else wants to make a contribution.
> Do they have to agree to both licenses? Or just the one? If someone
> contributes to the BSL licensed portion in Boost, how will you bring
> it over to the "real" Outcome?

It almost sounds like you have no experience of managing open source
libraries, yet you do.

Multi licence codebases abound in software, and in open source. Most
contributors are happy for their work to be licensed under whatever.
Even I, a long time staunch opponent of the GPL, suck it down when
sending in a patchset to a GPL codebase.

If a contributor were not happy with the Apache 2.0 licence, then I'd
rewrite their patchset. This almost never happens in practice. Apache
2.0 licence is highly uncontroversial.

> is by far the incompatibility with C++11 (currently in use by two-thirds of
> all programmers). Some libraries can get away with requiring higher versions
> of the language, but this isn't one of them. An error variant is sorely needed
> by ALL C++ programmers not just the one-third with the luxury of C++14 or
> higher.

However, Outcome is not an error variant. The first Boost peer review
clearly landed on a design which is not Expected.

Perhaps that's the problem here in truth. You want a C++ 11 Expected.
This library is not that. Hence you recommend rejection of this library,
irrespective of usefulness, irrespective of engineering, irrespective of
any other factor because you're not getting what you want, and I'm not
doing what you want.

What you should be saying is this: "This library does not suit my needs
or the needs of many others. So I'm going to submit for review a library
which does."

I'd be more than happy to see someone write a high quality Expected
implementation and submit it to Boost. It would complement Outcome nicely.

Niall

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