Re: Boost, not LEWG

From: Robert Ramey (ramey_at_[hidden])
Date: 2020-06-28 04:19:25

On 6/27/20 3:46 PM, Jeff Garland via Boost wrote:
> On Sat, Jun 27, 2020 at 9:02 AM Glen Fernandes via Boost <
> boost_at_[hidden]> wrote:
> 

> It used to not just be a bonus -- it's the prime reason Boost exists.  If
> it no longer has that mission we should make that clearer.

It was the reason Boost was founded, but once C++ standard absorbed most 
of Boost foundational libraries, Boost needed a new purpose.  There was 
much discussion of this around 2010ish but there wasn't much consensus, 
and we just continued without really thinking about it.

>> But Boost itself shouldn't compromise on quality - in its review
>> process or what it ships in a Boost distribution,   to serve any of
>> those other interests.

The only reason boost was successful, and continues to be is that it's 
one of the few places where one can acquire quality quality C++ 
libraries including code, tests, documentation, rationale, etc.  Vendor 
supplied C++ standard libraries also fulfill this role.  But the C++ 
standard can't evolve fast enough and vendors couldn't keep up in any 
case.  Hence the need for Boost.

> That is a decision for the Boost community to make, while there is still a
> community.  

That Boost must supply high quality software, and only such software, 
has been a fundamental premise of Boost since it's inception.  The 
decision was made long ago.  Of course the community could decide that 
quality could be de-emphasized in order to promote some other value(s) 
and that would be a decision for the community to make.  But so far I 
don't recall anyone proposing that.

If all C++ library development goes elsewhere then there won't
> be much left.

Hmmm - I don't understand what that means.  Is C++ library development 
going somewhere?

>> Putting a bunch of experimental libraries into a Boost release just
>> because people have proposed them for standardization is not something
>> we should do.

Hmmm - what does experimental mean in this context?  If means that 
quality has been compromised to get the job finished, we shouldn't do 
it.  If means some software which no one would ever think of putting 
into the standard (symbolic differentiation?), I wouldn't have any 
problem with it at all.  If someone want's to strike out with a whole 
new direction for character encoding, I would OK with that.  But what I 
would not be happy with is an incomplete/buggy/low quality of any of 
these things.

People use boost because:
a) it's documented
b) it works
c) it has passed a review process which certifies the above

The above saves user time - which the fundamental thing that they care 
about.

> I disagree.  Consider how painful it is for a c++ programmer that wants to
> contribute to the review proposed libraries for the C++ standard.  And by
> that I mean, go and use the implementation.  In my case I was doing this
> for c++20 -- it was super painful.  Aside from the time it took to go pull
> from different places, compiler support and library quality/robustness was
> all over the map.

How would Boost changing it's mission address this problem?

> After sleeping on it I like the idea more than ever -- so maybe I'll work
> on it.  And if Boost doesn't want to distribute it then it's more of the
> same mind share drain away from Boost.  I think it would be fine to ship
> the proposed elements outside the main distro until it went thru a normal
> review.  Ideally we'd get more authors to submit to a boost review and come
> under the tent.  Maybe we could have some of the 'boostification' work done
> by Summer of Code students.  Maybe this will led to more libraries like
> asio that can ship standalone and in Boost as well.

Note that the Boost Library Incubator (www.blincubator.com) was 
conceived to fulfill a role similar to that which you describe.  The 
requirements to be accepted into the incubator are objective and require 
not subject review.  The web site could/should be simplified/updated as 
much of the functionality is now better implemented within github 
itself. But in principle it seems similar to what you have in mind.

> Understood, but we should care about his effort to standardize.  Unicode is
> hard, it's a mess in C++, and average programmers could use a Boost (sorry,
> so sorry, not sorry :).  Ideally what Zach proposes will ship under the
> Boost banner first.  Why?   So more than the maybe 20 people on the
> committee will look at it before the ink is dried and it ships with
> compilers.

All true, but it should be good enough to pass a boost review before the 
committee decides to consider it.

Robert Ramey

PS: Off topic

TL;DR

The role, goals, methods, of the C++ library committee have been the 
subject of much discussion of late.  To many of us, it seems very clear 
that the process is not scaling and the committee as it currently 
operates can't keep up while still maintaining the level of quality that 
we and other users demand.  Something is going to have to change here, 
but of course we can never agree.

RR

> 
> Jeff
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>