Re: Future of C++ and Boost

From: John Maddock (jz.maddock_at_[hidden])
Date: 2022-05-06 08:10:07

On 06/05/2022 02:33, Gavin Lambert via Boost wrote:
> 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.
+1,  Nearly all my stuff has already used this leeway to move to C++11, 
OK so some of it hasn't transitioned to fully removing 03 support yet, 
but they will do very soon.
>
> 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.
Personally, there's little in C++14 that makes that move attractive for 
me.  C++17 yes (for if constexpr).  There may be a few libraries which 
could use the enhanced constexpr support in C++14, but otherwise I'm not 
sure how much practical difference this makes.  On the other hand, C++14 
is the current baseline for current compilers, so I have no objection to 
making this the current Boost baseline as well!
>
>
> 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.
Right, plus someone has to actually do the work.  For libraries that are 
basically dormant as far as development goes, I see little harm in 
leaving them as they are, even if they include atrophied C++03 
workarounds.  The workarounds will gradually wither anyway and get 
removed in time.
>
> 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.)

Agreed, but some older libraries could use upgrading for better C++1n 
support - someone mentioned initializer-list construction for bimap, I'm 
sure there are dozens of other small improvements that could be made.  
Many of them might even be pretty easy to do, we just need a TODO list ;)

Best, John.