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

On 8/30/2018 8:02 AM, Mike Dev via Boost wrote:

...

-----Original Message----- From: Boost 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