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-30 14:54:27

On 8/30/2018 8:02 AM, Mike Dev via Boost wrote:
>> -----Original Message-----
>> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Alexander Grund via Boost
>> Sent: Wednesday, August 29, 2018 3:12 PM
>>
>> So can we stop discussing "what does dropping... mean", reiterating the
>> obvious benefits and start talking about when and how?
> 
> Not sure, if I would call this a done deal yet and before any final decision is
> made, the thread should probably be open for more than a few days anyway.
> 
> However, there seems to be enough momentum and acceptance to push on
> and for now and for that we probably need some concrete text for the
> announcement (if it happens).
> Based on what King wrote earlier I would suggest something like the text below.
> Assuming everyone is happy with the general content, maybe Edward or someone else
> could take care of fully flashing this out (or write something completely
> different if you don't like it).
> 
> In general terms, I'd be happy to push this topic forward, but as I am in
> no way associated with boost except starting this thread, it may be best if
> someone else would take the lead.
> Also, I probably won't be able to write any more emails till end of next week.

The "pushing on" probably needs someone from the Boost steering 
committee involved.

>   
> Anyway here is my suggestion for the text:
> ===========================================
>> [Add some fluff here?]
>>
>> Starting from the first release of 2020 (probably 1.73) boost will
>> officially drop c++03 support.
>>
>> What does that mean?
>>
>>
>> First of all, on a general project level, no more time and effort will be
>> spend on qualifying or testing C++03 compatibility. Specifically,
>> - The default language level for b2 builds will be at least c++11 (if the
>>    compiler's default or the particular library doesn't specify a later
>>    version anyway)
>> - c++03 builds and compiler that don't support at least c++11 will
>>    be removed from the regular build matrix - for CI tests as well as for
>>    release testing.
>> - Problems that only manifest on not supported compilers [1] or in c++03
>>    mode will not block a release, and will probably not be fixed at all.
>> - Prebuild binaries on windows will only be provided for supported compilers
>>    *[1]*
>>
>> Second, individual libraries that are currently supporting c++03 may start
>> to use c++11 features unconditionally without prior notice or further transition
>> period.
>> As always, individual library maintainers are of course free to continue
>> their support of older language versions and compilers and we generally don't
>> expect the introduction of a lot of new c++11 code without a clear benefit.
>> However, many libraries may become incompatible with c++03 just by virtue of
>> depending on another library that previously supported 03 but now starts to
>> use c++11 features.
>>
>> Obviously, this change will only effect libraries that have supported c++03
>> before. Libraries that already supported compilers and/or newer language
>> versions are unaffected.
>>
>> If you want to continue to use boost in a project that has to stay compatible with
>> c++03, recommendation is to stick to the last release before the switch
>> (probably 1.72).
>>
>> [add some more fluff?]
>>
>> [1] We only consider the following compilers/toolchains to have sufficient
>>      c++11 support to be supported:
>>      - MSVC 2015 and up,
>>      - gcc 4.9 and up,
>>      - clang3.3 and up (when paired with an appropriate standard library
>>        implementation)
>>      - [ICC? CUDA? Any other?]

I would emphasize what toolchains are actually tested rather than 
supported toolchains. In general developers/maintainers care much less 
about toolchains than they do about C++ compiler levels and features in 
their library. If we say that we do not support Intel or Oracle 
compilers, for example, we are denigrating toolchains that may well work 
fine with most Boost libraries. If we explain which toolchains we 
regularly test, this then is an impetus for certain toolchains which we 
do not regularly test to offer ways/means to have those toolchains 
tested against Boost libraries. The more toolchains we can successfully 
test against Boost libraries the more end-users we have.

>>
> ============================================
> 
> Then, the documentation for each library should contain something like
> 
> ============================================
>> This library supports the following toolchains and language versions
>>
>> - [...]
>>
>> Other toolchains might work too, but are not tested and even if
>> they work with the current release, they might stop working with
>> without prior notice.

It is very difficult, if not impossible, for a library to know what 
toolchains are supported by that library. I agree that language level 
should be either in the documentation directly and/or in the meta 
information for each library, preferably both if the meta information 
can enable the Boost web pages to list the language level and/or 
language features used for each library.

> =============================================
> 
> Many (most? all?) libraries already have something like this anyway,
> but from 1.74 onwards (or whatever the version will be), I'd recommend
> to only mention pre-c++11 toolchains, if the maintainer is really
> committed to ensure compatibility for the next couple of releases,
> including internalizing any dependencies that might start to use
> c++11 in that time frame.
> 
> Two final notes from my part:
> 
> - First release in 2020 is just my initial proposal. If there is a
>    desire to apply that new policy earlier (e.g. end/mid of 2019)
>    that’s of course fine by me too.
>    Considering how previous discussions on that topic went down I
>    didn't want to suggest anything too aggressive, but still soon
>    enough to have any meaning at all. Also, I wanted the policy change
>    enacted before people would have to support yet another standard
>    (there will likely be more removals and deprecations from the
>     standard library in c++20).
> 
> - If this goes through, could someone create a c++11 branch (or similar)
>    in the github main project, where libraries that want to start early
>    can make their expected changes easily visible to others?

I think a c++11 branch as you have described brings an unneeded 
complication. Any library which currently supports c++03 and wants to 
use c++11 features will just do so. Since we wouldn't officially be 
testing at the c++03 level there is nothing further to do in 
transitioning, and each library developer/maintainer can continue to do 
his own local testing as he wants anyway.

Thanks ! I think your text is generally excellent.

> 
> 
> Destroy!
> 
> Mike