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

Subject: [boost] A possible date for dropping c++03 support
From: Mike Dev (mike.dev_at_[hidden])
Date: 2018-08-30 12:02:43

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

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

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?

Destroy!

Mike