Re: [boost] A possible date for dropping c++03 support

Subject: Re: [boost] A possible date for dropping c++03 support
From: Edward Diener (eldiener_at_[hidden])
Date: 2018-08-27 18:27:36

On 8/27/2018 10:56 AM, Mike Dev via Boost wrote:
>> -----Original Message-----
>> From: Boost <boost-bounces_at_[hidden]> 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