Re: Boost, not LEWG

From: Jeff Garland (azswdude_at_[hidden])
Date: 2020-06-28 15:43:06

On Sat, Jun 27, 2020 at 9:20 PM Robert Ramey via Boost <
boost_at_[hidden]> wrote:

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

I must have missed something bc I never got the change of mission memo --
despite being at 'future of boost' in Aspen every year.  Still, I mean it's
pretty clear that the mission has adjusted over time.   Part of the role
became supporting std library equivalents on older versions of the
standard.  Part of it is offering useful extensions that aren't in the
standard.  Part of it is offering useful libraries that won't ever go into
the standard.

But the original mission stands.  Before C++20 it was the case that a big
part of the new content was still rolling in older Boost libraries (aka
filesystem in 17).  Networking still hasn't made it there - it is a 23
priority.  Stacktrace might have a shot at 23 -- was close in 20, but ran
out of time. Peter and Glen moved some shared_ptr facilities into 20. I'm
helping to shepherd Process, because I believe that it should be there as
well.  So the pipeline isn't completely dead, but it's no longer the
primary input.

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

Yes it has -- standalone repos on github. As it stands, boost has NO
implementations of the c++20 major library changes (ranges, format, span,
chrono).  Maybe we will get jthread incorporated?  How about
synchronization primitives like barriers and semaphores? The container
erase algorithms?  Do we have scope_guard from the fundamentals TS that
someone might propose to go 23 - no we don't.  Will we have range library
extensions already being evaluated for 23 -- seems unlikely, given that we
don't have base ranges.  So the part of the community that in the past has
looked to Boost for 'bridge to a newer standard' is no longer being served
going forward.  And the part of the community looking at the future isn't
being served either.

Let me be clear that I'm not suggesting that we reduce quality and
consistency.  I'm just saying maybe we should think outside the box, like
you were with the incubator, for encouraging the rapid incorporation of
libraries proposed for the standard.  Maybe there needs to be some
concerted effort to make a case to library authors that it's worth their
time to be part of Boost. Maybe the path doesn't 'start' with the standard
review process.  Maybe it's a Boost23 package that can be unpacked on top
of the usual distro and has a set of boostified proposal libraries. If they
go through the review then they would just go into the distro of course.

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

Let's consider the format library which went into c++20.  It's substantial
and useful work moving output past i/o streams.  It's something that will
impact most c++ developers.  It's not in Boost, but in my view it would
have been even better if it had been in Boost.  There would have been more
scrutiny of some aspects earlier in the process.  The documentation would
have been better because a boost review would have forced that to happen.
And now there are extensions of that work being proposed -- but Boost isn't
in the loop at all.

Anyway, the 'implicit assumption' that the proposals and implementations
are necessarily of low quality bc they are not in Boost is incorrect.  But
as mentioned elsewhere the standard deviation is higher -- the level of
testing for most is clearly less bc they don't have 20 test runners on top
of the standard github CI to test their code.  Which means it may, or may
not actually compile and work in my environment.   Documentation is often a
casualty as the effort is in preparation of materials for the committee and
not for users.

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

I see it more as getting back to the core mission, but adapting to the new
realities.

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

Yeah, I agree there's a similarity.  I think the difference is I'm thinking
of an entire collection of libraries and not a single proposal.

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

The reality of the order is different -- the committee is already looking
at it and that is informing the design.

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.
>
> Sure -- scaling is hard.  And yeah, it's how the committee deals with that
is off topic for this list -- but it is clearly on committee members
minds.  On topic for this list is how WE, the boost community, deal with
that scaling and velocity of the current process in the committee.  Since
at least one of the missions is to in fact help said committee ensure the
highest quality library additions possible we might need some new
approaches in the current context.

Jeff