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 12:51:21

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 ?

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 ? 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.