On 10/22/18 1:49 AM, Niall Douglas via Boost wrote:
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.
This is what I'm talking about. Design by the standards committee is not a good use of the committees time and resources. If they insist on mandating libraries (itself a bad idea), the should just stick to evaluation of existing libraries.
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.
LOL - Right. This is what all organizations do when they are faced with the failure to accomplish their stated objectives. They add more objectives! The try to become too big to fail. Sears heads down the toilet and they ... buy Lands End. It's an all two familiar patter. What they need to do is cut scope back to something they can actually do a good job on.
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.
So he couldn't meet the requirements of Boost so it went to the standard. Boost standards exceed those imposed by the committee! This is why Boost is more successful than the committee in promoting development of quality libraries.
My main blocker for finishing Outcome is having to rewrite the documentation yet again. Everything else was finished six months ago.
I've had a lot to say about documentation. My advice to you and others with this complaint is that you must be doing it wrong. If you're waiting until the end of the process to add documentation, you're missing out on getting a better design. Here is what I have to say on the subject: https://www.youtube.com/watch?v=YxmdCxX9dMk Just follow these instructions and you'll find documentation a joy to write and the quality of your libraries will be much improved. You'll also find the review process, be it at C++ committee or at Boost, much, much less onerous - almost a pleasure. And you'll find that the review itself will be much, much more helpful than you've found in the past.
If Boost could start leveraging its ample cash reserves to solve the documentation problem, that would solve the problem.
Hmmm - I'm not seeing how spending more money would change peoples way of going about it. It's not a technical 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.
It would be free and alot easier if people just spent a little time learning how to do it properly.
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.
Hmm - once a library is standardized, I believe that vendors are required to provide it so that their compiler is considered "conforming". BTW - how a compile with easily demonstrable bugs are now considered "conforming" is beyond me.
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.
Personally, I've got no problem with "too niche" libraries. You're right they might have to scrounge around for a review manager. But as you note this is not a big problem.
[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.
If Boost were able to support modular deployment, this problem would go away. That is, if a library weren't being used, no one would download it and it wouldn't matter. Robert Ramey