On 8/27/2018 10:56 AM, Mike Dev via Boost wrote:
-----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.
So you are saying that if Boost announces that we are "dropping support for C++03" that a library which today does support C++03 and tomorrow does not support C++03 should not need to wait to do so ? I would say that end-users would not understand this as "dropping support for C++03" unless it were explained to them as part of what it meant.
================
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.
Try to put yourself in the place of end-users who are not involved in this mailing list. If Boost announced on their website that they are "dropping support for C++03" could you not realize that without a detailed technical explanation of what this is supposed to mean that the end-user would have no idea what such a message actually is about. This is the crux of why I have been trying to get you to say what this actually means at least to you, rather than it being just verbiage. If it is just an announcement, without any further technical changes to Boost, why say it in the first place. It will just serve to confuse people and not just me.
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 understand you. But a statement that "Boost is dropping support for C++03" will not directly translate in someone's mind to what you have just suggested above. It does in your mind because that is your interpretation of what it means. I would suggest that the statement that "Boost is dropping support for C++03" will much more likely translate directly in most people's minds to "I can no longer use the C++03 standard level of compilation when I work with any Boost library". Since that is not intended to be the case, even for those who would like to see Boost deprecate support for C++03 compilation, I would suggest that a Boost announcement of "dropping support for C++03" is not apropos and a more specific announcement vis-a-vis C++03 when using Boost would be more apropos.
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."
I have in the past highly encouraged library developers/maintainers to specifically include in the documentation to their libraries the level of C++ standard support that is needed to use their library. I personally think that information should be front and center in the introduction to every library, even if I have been perhaps as remiss as anyone else in providing it.
@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