Re: Future of C++ and Boost

From: Gavin Lambert (boost_at_[hidden])
Date: 2022-05-06 01:33:10

On 6/05/2022 12:08, James E. King III wrote:
> 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.

As far as I was aware, it was already agreed several years back that 
maintainers of individual "leaf" libraries could decide to stop 
supporting pre-C++11 pretty much whenever they like (one or two versions 
of deprecation warning appreciated), and that new libraries did not need 
to be backwards compatible.

It's a little murkier for libraries that are depended on by other 
libraries; there you had to get consensus from the downstream library 
maintainers to stop supporting pre-C++11 too, either simultaneously or 
earlier.

I would personally argue that it makes sense now to move that forward to 
C++14 rather than C++11, but I don't think that's actually been formally 
discussed yet.

There's a certain amount of resistance to "forcing changes" on libraries 
that don't really get touched year-to-year, because changes require work 
and have potential to introduce bugs.  While there are some benefits to 
rewriting older code to remove workarounds and use more modern patterns 
(making future maintainability easier), there is still merit in that 
reluctance.

But agreeing to stop supporting C++03 does not necessarily require code 
changes -- the absolute minimum would be to just stop running the CI for 
it, and an only slightly higher bar would be to change the build 
settings to refuse to compile.  (Although some people are reluctant to 
go even that far -- if they're not actually changing the library to take 
advantage of C++11 then there's no technical reason why it wouldn't 
compile under C++03, so why block it?  But there can be non-technical 
reasons why this may still be a good idea.)

There's also some complexity in what "stopping supporting C++03" means, 
even if the maintainer does want to make code changes.  Like it or not, 
there are differences between std:: and boost:: classes even where those 
largely intersect (e.g. threading, smart pointers, optional) and some 
have features or support that the other lacks.  But even where 
functionality is sufficiently identical, swapping is an API-breaking 
change that will require edits to all downstream code -- probably 
trivial ones, and which the compiler will readily identify for you, but 
still there nonetheless.  And there's a certain reluctance (rightly or 
wrongly) to impose that as well.  There was an attempt a while ago to 
make this the end-user's responsibility to choose between the 
implementations via macros and policy templates, but it didn't really 
catch on (and I'm not convinced that it should).

Given that C++ itself is largely backwards compatible (and despite the 
trash-talk I and others often give it for using the wrong defaults for 
everything as a result, this is a good thing); it's usually not hard to 
migrate an application code-base from C++03 to at least compiling 
without issue in C++14 or beyond, even if not taking advantage of new 
features or idioms.  So it should not be a difficult barrier to say 
"hey, update to C++ab or this library will stop working".  Applications 
and compilers already have to cope with a mixture of different standard 
levels intersecting.