-----Original Message----- From: Boost
On Behalf Of Edward Diener via Boost Sent: Monday, August 27, 2018 6:21 AM You are correct in that I do not understand why making an announcement that Boost is "dropping support for C++03" is going to make any difference to anybody, when nothing further changes as far as Boost is concerned and in fact some Boost libraries continue to support C++03 simply because they do not require C++11 on up features.
Happy to quote myself again ================ You as a library programmer should know better than anyone else that there is a difference between supported (and hopefully) documented API behavior, which you are committed to support and implementation details that might change at any moment (and don't get me started on UB that happens to do what you expect in a particular version of your compiler). Currently, many libraries are committed to support c++03, meaning they won't just start to use c++11 features [unconditionally] without prior announcement and some transition phase. After officially dropping c++03 support (with prior announcement and appropriate transition phase), whether a library happens to still compile with c++03 or not becomes an implementation detail that might or might not change with every new revision. ================ Now, disagreeing with or not understanding my arguments is one thing, but the fact that you keep completely ignoring what I'm saying or even worse insinuating that I would suggest things when I actually stated the exact opposite makes me wonder if you try to have a discussion with me or rather just reflexively answer to anything that contains "drop support for C++03" with some default statements of yours, because I'm just the next guy suggesting to "drop c++03 support".
And if something further is actually supposed to change regarding Boost other than making such an announcement, I would love to hear about what it is from you. I do not believe in doing something for no particular reason just because someone thinks it sounds 'good'.
I am also curious about what documentation is supposed to be changing when you say "changing the documentation".
If I seem belligerent it is because you are only the last of a stream of people saying that Boost should "drop support for C++03" without saying what in particular this is supposed to entail, other than Boost supposedly announcing that this will be the case.
That is the point: It is not supposed to entail anything more than that. Now, there are a lot of things I *would like to do* if support for c++03 is dropped on a boost wide level, such as - Deprecating libraries and types that have been merged into the standard (why spend the effort of maintaining them). - Removing internal dependencies when they can be replaced with c++11 standard library or language constructs - Remove conditional compilation paths - Reduce test matrix (removing all compilers that can't compile in c++11 mode and making sure every test is compiled with at least c++11) - Migrate libraries from mpl to mp11 - Simplify some code paths where possible. A library might not require c++11 features, but almost any library I've seen can profit from c++11. (some of those changes I actually have already done in private forks of boost libs) But regardless of what is discussed and/or decided on the ml, none of the library maintainers could be forced to accept any of those changes anyway so I don't see the point of discussing those here. I'd rather discuss specific changes with the responsible maintainer in an issue/PR at the respective github repository. However, officially dropping c++03 support (boost wide) would get rid of problems like this this: "Oh I'd like to apply that change to library A, but that requires at least c++11 and the boost libraries X,Y,Z depend on A compiling in c++03 mode, so I can't do it without announcing the switch on the ml and then wait for a year or so until they have found an alternative - so sorry, but that's just not worth it" because if your library is not officially supporting c++03, no one should rely on that anyway regardless of whether it works at the moment or not and if they do rely on it anyway, it is their problem. (see my above argument about supported API behavior vs implementation details)
I am also curious about what documentation is supposed to be changing when you say "changing the documentation".
I think you started mentioning changing the documentation first, but either way, what I'd expect is a note *along the lines of*: "This library is supporting compilers x, y, z and supports c++11 and upwards language standards. Compilation with an older compiler or in c++03 mode may be possible, but is not supported any may break with any new release without prior notice." @degski Personally, I'm much more interested in code simplification and reduction of dependencies than (run-time) speed improvements, but of course others have different priorities. Best Mike