Re: Dropping C++03 support (again)

From: Tom Kent (lists_at_[hidden])
Date: 2023-02-07 02:31:07

On Sat, Feb 4, 2023 at 8:52 AM Matt Borland via Boost <boost_at_[hidden]>
wrote:

> On Sat, Feb 4, 2023 at 04:46, Andrey Semashev via Boost <
> boost_at_[hidden]> wrote:
>
> > On 2/4/23 15:08, Peter Dimov via Boost wrote:
> >> Greetings,
> >>
> >> I have a novel idea, let's drop C++03 support.
> >>
> >> The reasons to do that have been explicated already
> >> a number of times, e.g. in
> >>
> >>
> https://pdimov.github.io/articles/phasing_out_cxx03.html#_ongoing_costs_of_maintaining_c03_support
> >>
> >> but in brief:
> >>
> >> * C++03 is 20 years old.
> >> * A number of intra-Boost dependencies can be
> >> eliminated by using the standard equivalent of
> >> Boost components. This will help Boost to become
> >> "more modular".
> >> * Variadic templates allow us to remove the uses
> >> of Preprocessor and MPL, which are the primary
> >> contributor to slow Boost compilation times.
> >> * Almost no new C++03 development occurs in
> >> Boost at this point, so C++03 users do not need
> >> to upgrade their Boost.
> >>
> >> To that end, I propose the following:
> >>
> >> Boost release 1.82.0 is announced as the last one
> >> with C++03 support. If critical problems are found
> >> in it post-release, we will issue 1.82.1, 1.82.2 and
> >> so on, as appropriate (as C++03 users will not be
> >> able to just upgrade to 1.83.)
> >
> > For this to be possible, a separate set of branches need to be created
> > for each library and the superproject. Possibly, CI scripts needs to be
> > updated to test the new branches.
> >
> > Also, I suggest we name the first Boost version that requires C++11 as
> > Boost 2.0 and the C++03-compatible releases continue to be 1.x. The
> > compiled binaries for 2.x should be named differently from 1.x, i.e. add
> > a new tag in 2.x binaries. This will make it easier for downstream
> > consumers to ship 2.x and 1.x releases side by side, should it be
> > needed. Point releases may not be convenient for downstream since, for
> > example, Debian dev packages for Boost are named as
> > libboost-math1.74-dev (no point version).
> >
> >> Boost release 1.83.0 is announced to require C++11
> >> at minimum. This means compilers that have all the
> >> C++11 standard headers, and support all the C++11
> >> syntactic constructs and keywords without issuing
> >> errors. (E.g. VS2013 doesn't qualify because it doesn't
> >> support the `constexpr` or `noexcept` keywords.)
> >
> > For gcc, the minimum version would be 4.8.1:
> >
> > https://gcc.gnu.org/projects/cxx-status.html#cxx11
> >
> > For clang, it's 3.3:
> >
> > https://clang.llvm.org/cxx_status.html#cxx11
> >
> > _______________________________________________
> > Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
> When we were converting Math to C++11 we found that the practical minimum
> for GCC was 5. If I remember correctly GCC 4.8 series <type_traits> support
> is broken. We don’t have any Clang earlier than 5 in the CI system either.
>

I'm guessing that you're referring to a specific CI system?

The regression test do run against Clang 3.x:
https://www.boost.org/development/tests/develop/developer/summary.html

Specifically, the oldest compilers we're currently testing against are:
gcc-4.6
clang-3.3
msvc-10.0

I'd personally support the community phasing out support of the older ones
and make it:
gcc-4.8 (Default in RHEL 7 and Ubuntu 18.04 LTS)
clang-5
msvc-14.0

Tom