Re: Future of C++ and Boost

From: James E. King III (jking_at_[hidden])
Date: 2022-05-06 00:08:44

On Thu, May 5, 2022 at 3:27 PM Mateusz Loskot via Boost
<boost_at_[hidden]> wrote:
>
> On Thu, 5 May 2022 at 17:51, James E. King III via Boost
> <boost_at_[hidden]> wrote:
> > On Thu, May 5, 2022 at 10:59 AM Mateusz Loskot via Boost <boost_at_[hidden]> wrote:
> > > On Thu, 5 May 2022 at 16:26, Kostas Savvidis via Boost <boost_at_[hidden]> wrote:
> > > > [...]
> > > > In other words, boost needs to shrink not grow.
> > >
> > > I mostly agree, but I'd say Boost needs to undergo a restructurisation to
> > > remain attractive to all generations of developers, maintainers and users.
> > >
> > > I can't see it happen unless we have separate superprojects:
> > >
> > > github.com/boostorg/boost  (require>=C++17)
> > > github.com/boostorg/boost11 (>=C++11 )
> > >
> > > and, if still relevant, perhaps:
> > >
> > > github.com/boostorg/boost03
> > >
> > > As a maintainer, I'd like to be free to maintain a library
> > > only for e.g. boostorg/boost and forget about
> > > boostorg/boost11, or let new maintainer to take it
> > > over there.
> >
> > About shrinking boost:
> >
> > I see no reason to have separate superprojects for different language
> > levels.  Why not simply have a concerted effort to remove C++03
> > support?
>
> Why not simply have a concerted effort to remove C++11/14?
>
> Well, we as a community need to make space for everyone,
> those who want 03, those who want 11, and those who aim higher.
> Like we did it for those who want Boost.Build and those who want CMake.
>
> Otherwise, we will end up whipping the cream, again, and nothing will
> happen, again.
>
> I can't see making the space (and making the Boost more inclusive) w/o
> separate superprojects.

I disagree with you here.

Past versions of Boost which are stable and released do support C++03.  The work
to support the language level has already been done and it is
available for all to use.
There is no good reason to saddle future development to it.

This group as a whole needs to move forward.  It is in the same state as I
left it in 2018 to start my own company... a lack of consensus to make forward
progress.  Dropping C++03 and establishing a new baseline, and creating rules
for backwards compatibility is what all other projects do.  I see no
reason for Boost
to deviate.  If there are people who cannot use C++11 for some reason, they can
use older boost releases.  We are not leaving anyone behind.  They have options.
It is up to us to move forward; it is up to them to decide if they
also want to move
forward.  It is not our responsibility to be their savior for all
things C++ if they decide
not to embrace the future.

As a point of comparison, I offer you this:

- In Python there is a clear definition when a language level will no
longer be supported:
https://devguide.python.org/#status-of-python-branches

- In node.js there is a clear definition when a language level will no
longer be supported:
https://nodejs.org/en/about/releases/

- In Ruby there is a clear definition when a language level will no
longer be supported:
https://endoflife.date/ruby

- In Perl there is a clear definition when a language level will no
longer be supported:
https://endoflife.date/perl

Now, you may argue that these are language levels and not libraries.
I would counter that
Boost is no ordinary library.  Given the size and scope of the Boost
C++ libraries they are an
entire ecosystem unto their own.  They deserve the same treatment as a
language level.

Therefore I would propose, again, that Boost officially adopt the
philosophy that it establishes
a support baseline of the current C++ language level and the prior
three.  This is VERY
lenient in relation to the other links I posted.  This means currently
we have C++20 and we
will officially support C++17, C++14, and C++11, to the extent a
library is not specifically
designed for a newer language level than that.

I for one would enjoy updating Boost.CI and the 16 Boost libraries
that I maintain to stop
running C++03 tests through CI and stop claiming support for utterly
ancient EOL compilers,
as well as language levels.

This is a small step forward.  We should all consider taking it
together.  As a community we
need to make progress in some capacity.  In the past it has been
impossible to achieve
a consensus on things like this.  We need to come together to move
forward.  In the lens of
looking to where Boost will be in 20/50 years from you, this will go a
long way to ensuring that
the future of Boost is not saddled with impossible backwards
compatibility matrices.  We had
these same discussions 5 years ago and ended up getting nowhere.  We
cannot let this happen
again.

- Jim