Am 24.10.18 um 18:43 schrieb Peter Dimov via Boost:
Mike Dev wrote:
We can switch to std::function unconditionally, but only if we drop C++03 (for some definition of C++03 because only the latest and greatest > MSVC is ~fully C++11 compliant.)
That's my point: I don't want boost libraries to invest any more effort in maintaining c++03 support (I think I made that clear in the last ml-thread about this 2-3 month ago).
It's clear to all that everyone is held back by the inability to use C++11 things.
But we can't just stop investing effort in C++03 maintenance. We have to officially drop C++03 at the Boost level, meaning, refuse to compile Boost with C++03 at all, or make it difficult, or at least make it choose an intelligent default that is never C++03.
Otherwise it's easy for our (g++ 5 and clang) users to end up with Boost libraries compiled with C++03.
One thing I really do not understand is: Why should people use the newest and latest Boost version when they are stuck with an ancient compiler or code-base, which does not even support C++11? Do they really need the newest libraries from Boost? (Most of them require at least C++11 anyways.) Isn't it enough for them to stick to one Boost version that has all the needed Boost libraries and worked for a long time and be happy? OK, if they want to have the latest (security-)bugfixes, then they should get them as patches or as patch-releases of the same (old) version. My recommendation is therefore: 1. Announce that e.g. Boost 1.70 will be the last release that guarantees to compile with C++03 and that you will support it for some (longer) time by providing patch-releases (1.70.1, 1.70.2...), only including (security-related) bugfixes but no new features. (You need specific git-branches for this and they will differ over time from develop/master branch. 2. Create a new Boost 2.0 release (instead of Boost 1.71) which no longer guarantees to compile with C++03 and which guarantees to compile with at least C++11 (or better C++14). Then, for every new Boost 2.x version, you are free to remove as much C++03-only libraries or update other libraries to no longer support building with C++ standards older than the minimum required standard for Boost v2. 3. Some years later, you could create a new Boost 3.0 release which then might only guarantee to compile with at least C++17 (or C++20). And the latest Boost 2.x version will only receive (security-related) bugfixes. 4. Do the same every few years for new standards (if appropriate). You effectively would guarantee to support the latest C++ standard with the newest Boost version while gradually removing parts that no longer are required for compiling with that standard.
(Of course this just kicks the can a bit further down the road - we'll then need to pick between 11 and 14 as a default for g++ 5 and clang...)
Btw.: Feature/library wise, I believe the only c++11 thing missing from MSVC2015 is full constexpr support and expressions sfinae and even MSVC2013 provides most of the library and language bits.
The point is that "C++11" is not useful as a requirement when it comes to MSVC, we need to pick a specific minimum version. 2013 is a good approximation of "C++11", I suppose.
I think, the best would be to make a hard cut. Find a good release (e.g. Boost 1.70) you might want to support for some time for "old" compilers while meanwhile go on with newest compilers that (fully) support the latest (minimum-)standard for your Boost Major-release. If e.g. only VS2017, GCC 7 and Clang 8 would fully support that minimum-standard, then these compiler versions will be the oldest compilers supported by the newer Boost versions. I really think at one time you have to drop backward-compatibility, at least for ancient compilers and standards. Just my 2ct, Deniz Bahadir