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

-----Original Message----- From: Boost On Behalf Of Edward Diener via Boost Sent: Thursday, August 30, 2018 10:54 PM

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

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

Sounds right. I admit I've no idea about things like this work in boost

...

...

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

Agreed

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.

Well, with the projects I was involved we didn't support what we didn't test ( or rather we decided what we wanted to support and tested the heck out of it) but sure, use whatever term you think is more appropriate in this context.

...

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

Just to make sure there isn't a misunderstanding: the c++11 branch would be for the time frame from now until boost 2020 where those changes could the be merged to develop and then master. Maybe c++11 is a bad branch name. In normal sem-ver terms it would be the creation of a branch for the next major version while there are still 1-2 more minor version upgdates in the making. But you are probably right and anyway it can wait.

Thanks ! I think your text is generally excellent.

Thanks