Re: [boost] The future and present of Boost

Subject: Re: [boost] The future and present of Boost
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2018-10-22 08:49:31

> All one has to do to see this is look at the papers list for the San
> Diego meeting.  Also look at P0977r0.  Consider that it take the
> committee 10 years for a proposal to evolve into something that can be
> delivered to users. It even takes 10 years to include something which is
> already in use by 100's of thousands of programmers - ASIO.

In fairness, this is because its champions refuse to split ASIO into the
bit everybody agrees with - the synchronous API - from the bit which is
dependent on stuff not finished i.e. the asynchronous API.

If its champions were willing to fold deadlines/timeouts into the
synchronous API and leave off the asynchronous API for C++ 23, they
could ship, now, for C++ 20. So in the end the lack of any Networking in
C++ 20 is 100% down to its sponsors and champions, not the committee who
have repeated pleaded - even formally by Direction itself (P0939) - to
get Networking into C++ 20.

> Of course the C++ committee won't address the situation.  Committees
> don't do that. They think they can remain relevant by expanding scope.
> and lo and behold, now they want to expand scope again to include
> tooling.  Wake up and smell the coffee people.  Learn to prioritize and
> limit the scope of your actions to that which only you can do.  This
> would be better for C++.  Do less - get more done!

You may not yet be aware that WG21 is launching lots of new SGs, and
spitting LEWG into pre-LEWG and LEWG all as part of handling better the
increased workload. Its scope has markedly increased from even a few
weeks ago.

And now to Antony ... On 21/10/2018 19:33, Antony Polukhin via Boost wrote:

> Ranges is a very popular library. It is still an "existing practice", but
> that practice is not from Boost.
>
> Here's a crazy idea - include into Boost all the prototypes that were
> accepted into C++. This will keep the Boost important and usefull. Users
> will be able to find all the upcomming libraries in one place.

Eric Niebler is on record saying the primary reason he didn't submit
Ranges v3 to Boost was the documentation requirement, which was onerous.

My main blocker for finishing Outcome is having to rewrite the
documentation yet again. Everything else was finished six months ago.

If Boost could start leveraging its ample cash reserves to solve the
documentation problem, that would solve the problem. So, specifically
speaking, each year the Boost SC allocates a fixed chunk of cash for
documenting some reference library implementation of an approved
upcoming C++ standard library. A popularity vote is held by Boost on
which of the choices should win this. The winner has professional
technical writers hired to write the documentation. The finished result
appears on boost-dev for a mini-review. If approved, it enters Boost.

Speaking personally, I have something like five reference library
implementations before standards now. All lack documentation, and I have
no intent to write any beyond what is there now. I personally wouldn't
mind investing the work to get some or all of those into Boost, BAR
writing the documentation.

I can't speak for Eric or Casey, but I can see that for them the
additional work to enter Boost - bar the documentation - is fairly
insignificant compared to what has already been invested for standards.
They may well be willing.

Ultimately though somebody needs to create consensus to do this here on
boost-dev, ask the Boost SC for the funding, and then run the annual
competition. Boost has the money, there are lots of Boost-quality
standards reference libraries to choose from. Just somebody needs to do
the admin to make it happen.

> Another idea: how about dropping the "review manager" requirement? Allow
> library author to manage the review and require a separate manager only if
> the votes for library inclusion are doubtful or there's less than N votes.

I'd strongly oppose this, except where a review manager can be
substituted by WG21 having formally decided to standardise a library.

I appreciate lack of review managers gates the number of new libraries
in Boost [1].

But, to be blunt, Boost is about *popular* libraries. If a library can't
find a review manager, not enough enough of an itch is there to be
scratched. That's the whole point of having review managers, to filter
out too-niche libraries.

[1] I really, really, really, really wish Boost would expunge the
undermaintained libraries already. They waste productivity for so many
people out there who think they're using a Boost quality library, when
they're not, and get badly burned for it.

Niall