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-26 18:33:27

On 8/26/2018 12:23 PM, Mike Dev via Boost wrote:
>> -----Original Message-----
>> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Edward Diener via Boost
>> Sent: Sunday, August 26, 2018 8:51 PM
>>
>> On 8/25/2018 11:07 PM, Mike Dev via Boost wrote:
>>>> -----Original Message-----
>>>> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Robert Ramey via Boost
>>>> Sent: Sunday, August 26, 2018 3:17 AM
>>>>
>>>> On 8/25/18 12:51 PM, Mike Dev via Boost wrote:
>>>>>    From the discussion about abi compatibility when the Boost.System library is
>>>>> compiled e.g. in c++03 mode and then included in ac++11 project or vice
>>>>> versa
>>>>> (https://groups.google.com/forum/#!topic/boost-developers-archive/EWG5NVOZo_
>>>>> g)
>>>>>
>>>>>>
>>>>>> When can we drop C++03 support? :D
>>>>
>>>>
>>>> My understanding has been the boost only requires that libraries be
>>>> conforming to the current C++ standard. I don't think that requires for
>>>> support for C++03
>>>
>>> I certainly didn't want to claim otherwise as a lot of libraries already require
>>> c++11 or later. However, I'm talking about dropping c++03 support in libraries
>>> that did support it till now.
>>>
>>> Considering the strong internal coupling between older boost libraries,
>>> an individual library can't drop c++03 support without this decision
>>> affecting many, many other boost libraries. And while external users that
>>> can't migrate to c++11 have the option to just stick to an older boost
>>> version, internal users (aka other boost libraries depending on it)
>>> can't do that.
>>> So, let's say the maintainer of Boost.iterator wants to drop c++03 support
>>> and start using c++11 features. That would mean that at least a dozen or so
>>> other libraries that depend on it would suddenly also no longer be c++03
>>> compatible without them having any say in it.
>>> If I were a boost library maintainer I'd certain not want to make the switch
>>> to c++11 under those conditions, even if I'd do it with a standalone library
>>> for which I can just release a new major version. This is, why I think,
>>> such a decision needs to be made by all affected maintainers (or at least
>>> by most of them) together.
>>
>> You have things backward. How can all maintainers decide what level of
>> C++ support a particular library should have ? Library X has features
>> which determine what level of C++ support it needs. Simply because
>> dependent libraries A, B, and C use library X they certainly can not
>> decide for library X what level of C++ support it should have ?
>>
>> I think you do not seem to understand that a library's level of C++
>> support depends on the C++ language and library idioms it uses, not on
>> some theoretical need to support some level of the C++ standard. If a
>> library works at the C++03 level and Boost decides to "drop C++03
>> support" in your terms, what do you actually propose to do with such a
>> library ?
>>
>> I would really like to know your answer to that ?
>>
> 
> For almost all c++ libraries I'm aware of, the supported minimal c++ version
> is a project management decision that comes first and based on that decision,
> the developers use the features that are available to them (or enable later
> features only conditionally via the preprocessor). Essentially it is a
> tradeoff between being usable by as many projects as possible vs doing without
> all the nice features that the new language standard provides
> 
> Of course, over time, project management might decide to drop support certain
> c++ versions as client needs change (no need to stay compatible with c++03 if
> none of your clients' needs that compatibility).
> 
> For boost, the clients are not only external users but also other boost libraries
> that might want to provide c++03 compatibility to their clients and while no one
> is *forced* to keep his or her library compatible to c++03, it creates a certain
> level of peer pressure if you know that if you start using c++11 features, the
> libraries that depend on you can also no longer be compiled in 03 mode or have
> to implement the functionality themselves
> (I mean no one wants to make life difficult for their colleagues right?)
> 
>> Are you going to force it to use some C++11 on up feature in its code so
>> that it no longer compiles at the C++03 level, even when it has no use
>> for any C++11 on up feature anywhere in its implementation ? I am sure
>> you realize how silly that would be. Are you going to drop the library
>> from the list of Boost libraries even though the library works perfectly
>> well with users who compile it with C++11, C++17, or C++20 levels ?
> 
> Where do those ideas come from?
> 
>  From my initial post:
> ============
> And before someone starts to raise straw mans: That of course wouldn't mean
> that a particular library *must* no longer compile in 03 mode, but one can
> no longer rely on the boost-internal dependencies remaining c++03
> compatible.
> =============
> 
> or from my second mail:
> 
> =============
> I would certainly not expect that you start ripping out the guts
> of an old, battle proven library and replace everything with c++11
> features just for the fun of it.
> =============
> 
> I don't know why this has to be repeated over and over again.
> 
>> That
>> would really be absurd. Do you want to make an announcement on the Boost
>> web page that Boost libraries which support C++03 may not support that
>> level in the future and therefore Boost end-users are encouraged to use
>> a higher level of C++ when using Boost libraries ? That might be
>> reasonable, but then again we can say that for any library, ie. that it
>> might only work in the future with a higher level of the C++ standard
>> than it currently supports. So now can you see why your suggestion of
>> Boost "dropping support for C++03", like others in the past who have
>> said the same thing, is so generally meaningless ? It is because
>> practically there is nothing to be done except perhaps a general
>> announcement on the Boost web page, and even that has no affect on
>> libraries which support C++03 right now, nor should it.
> 
> I wonder if the reason it appears meaningless to you is because you deliberately
> want to misunderstand the suggestion.

No, no, no ! It is meaningless because you continue to talk about this 
in generalities as if it were a philosophical question that some sort of 
agreement is going to solve rather than offer any sort of practical 
example of what "dropping C++03 support" actually entails. At least 
Peter brought up some practical suggestions, but you just want to keep 
parroting some idea without offering any practical solution to what it 
should actually happen. You seem to think that some sort of announcement 
is magically going to cause a change to libraries which support C++03. 
Sorry to burst your bubble but that is not going to happen, nor should 
it. Telling some library developer/maintainer that they should use some 
C++11 on up feature for the sole reason that it will require that 
library to only work with C++11 on up is so illogical that I really can 
not believe a computer programmer could even think in those terms.

> 
> 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 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.
> 
> Best
> 
> Mike