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.