Subject: Re: [boost] The future and present of Boost
From: Deniz Bahadir (dbahadir_at_[hidden])
Date: 2018-10-24 18:12:24
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