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: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2018-01-31 01:08:45

On Tue, Jan 30, 2018 at 4:09 PM, Niall Douglas via Boost
<boost_at_[hidden]> wrote:
> Firstly, Boost admission requirements are merely that it conforms to the
> latest published ISO C++ standard. That's currently C++ 17.

I am familiar with the letter of the law.

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

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

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:

<https://www.jetbrains.com/research/devecosystem-2017/cpp/>

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

Again, this is within the letter of the law. But is not Best Practices.

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

> a.k.a. you don't like me, so no Boost for you. Ok.

This has nothing to do with whether I like you or not. For better or for
worse, a Boost library comes with the author attached. How they conduct
themselves prior to inclusion is a good indicator of future performance.
As you stated yourself in the previous message, you may just add out
of scope items to your library once it is accepted. This is precisely the
type of decision-making I object to (not the person making 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.

No, that's not correct. I don't feel entitled to anything. My largest objection
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.

Making Outcome work flawlessly in C++11 and on the popular compilers
including the one I use would be a significant accomplishment and reflect
very positively on the skill and professionalism of the author. Of course, the
converse is also true...

> But perhaps you should look instead at how Outcome was done: I took the
> (very) long way round on getting this library into Boost

Yes, and I think this reflects positively on you. I see a lot of effort and work
that went into this thing, and you have invested a lot of time and energy
responding to everyone on the list and to the users. This is to your credit.

I think if Outcome was usable in Beast (C++11 and a reasonably modern
version of Visual Studio) I would be leaning towards ACCEPT rather than
REJECT.

I appreciate your thoughtful reply.

Regards