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.