[Development] Raising the minimum to C++20

[Maurice Kalinowski]

As Marc already mentioned, we are having troubles with users not being able to upgrade on various platforms.

We even have customers who are not able to upgrade to C++17 yet due to supply chain issues.

Basically, the idea from our end has been to take a two-step approach by first enabling every developer to use C++20 in their projects and potentially add helpers/functionality where possible. Only at a later stage we can then start using it in Qt itself. Vladimir Minenko has all the details, as he has been laying out the rough plan with the foundation engineering.

This certainly is a good topic for a contributor summit, to which extend we want to establish fixed rules for those types of upgrades.

BR,
Maurice


> -----Original Message-----
> From: Development <development-bounces at qt-project.org> On Behalf Of
> Marc Mutz via Development
> Sent: Wednesday, 3 May 2023 07:51
> To: development at qt-project.org
> Subject: Re: [Development] Raising the minimum to C++20
> 
> Hi Thiago,
> 
> While I'd rather sooner than later see us switch to C++20, ever since
> 5.7, we have dropped supported compilers only after an LTS release (5.6,
> in that case).
> 
> Since I agree the train for 6.6 has left the station, as Integrity (and
> possibly QNX?) don't have an official C++20 offering, yet
> (https://ghs.com/products/compiler.html, IIRC, they're going to release
> one this year, but I don't know what features they're shooting for), I
> was assuming that 6.9 would be the next option.
> 
> Personally, I would support a break after 6.8. That's scheduled for
> release in summer/autumn 2024, and has three years LTS, so gives
> affected customers until autumn 2027 to update their tool-chains. By
> that time, C++26 will be out already.
> 
> Even that, within TQtC, is seen as too early by some. After all, we
> still support 5.15 and therefore C++11, in 2023. That's only because
> 5.15 is a VLTS release, though. TQtC could decide to make 6.8 such a
> VLTS release, too, if sufficient numbers of customer won't be able to
> upgrade to C++20 by 2027.
> 
>  From a maintenance POV, it should be easier to support a C++17-based
> VLTS release than one that's still stuck on C++11 (and doesn't actually
> test for compatibility with that version in the CI...).
> 
> Thanks,
> Marc
> 
> On 03.05.23 02:39, Thiago Macieira wrote:
> > C++23 is on the way, so maybe it's time for us to raise our minimum to the
> one
> > version before that. Let's aim for Qt 6.7, because feature-freeze for 6.6 is
> > within one month, and lets us warn our users this is coming.
> >
> > By this, I mean to:
> > * modify our build system so Qt compiles with -std=c++20 or equivalent
> > * require that user code compiling Qt headers be similarly done
> > * remove the requirement for #if checks for C++17 Standard Library features
> > * make a couple of C++20 features mandatory (see below)
> >
> > Of the C++20 features I currently see a good reason to make mandatory:
> > * feature-test macros (no change: we're already using them)
> > * spaceship operator and <compare> header
> > * char8_t
> > * std::is_constant_evaluated()
> > * constinit
> > * <bit> header
> > * (maybe) designated initialisers
> > * (maybe) constexpr from <algorithm> and <utility>
> >
> > I'm not proposing modules, concepts or coroutines be allowed in our code
> just
> > yet. I think concepts will be the first of those, but we need to understand
> how
> > to use them first and how our code will change. I'd love to require
> std::format
> > and std::source_location, but those don't seem to be ready in the proposed
> > versions above.
> >
> > For this, I'd also like to request we raise our minimum compiler versions to:
> > * GCC 10 (released May 2020)
> > * Clang 10 (released March 2020)
> > * MSVC 2022 that is current today
> > * XCode that is current today
> >
> > Clang and GCC will be, at the time of Qt 6.7's release, just under 4 years
> > old. That should be enough to have been included in any long-term support
> > Linux distribution. Currently, both SLE 15.4 and RHEL/RockyLinux 9 have GCC
> > 13, while Ubuntu 22.04 and Debian 11 (current stable) have GCC 11. Debian
> will
> > probably release its next stable before Qt 6.7, though whether it'll still
> > upgrade from GCC 12 to 13 I don't know. When we released Qt 6.0, our
> minimum
> > of GCC 8 was of a lower age, at 2.5 years, so we could reasonably bump our
> > minimum GCC to 11 and still be 6 months more lenient. There are no new
> > features in GCC 11 that we could use without also requiring a more recent
> > Clang.
> >
> > Speaking of Clang, I simply chose a contemporaneous version and one that
> had a
> > similar feature list. FreeBSD 13-STABLE (13.2) comes with Clang 14, which is
> > much newer. We could raise the minimum if we wanted, but the intersection
> of
> > features with GCC 10 or 11 doesn't change much; we get std::bit_cast with
> > Clang/libc++ 14, but that's about it.
> >
> > This proposal also drops MSVC 2019 and assumes that users of 2022, like
> XCode,
> > keep their compilers reasonably up-to-date. That is, that they'll update to
> > the latest at least once in the next 10 months.
> >
> > I don't have access to QNX and INTEGRITY toolchain information, so I'd like
> to
> > request that they simply match the feature list above, with minimal
> > workarounds.
> >
> > Opinions?
> >
> >
> --
> Marc Mutz <marc.mutz at qt.io>
> Principal Software Engineer
> 
> The Qt Company
> Erich-Thilo-Str. 10 12489
> Berlin, Germany
> www.qt.io
> 
> Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
> Sitz der Gesellschaft: Berlin,
> Registergericht: Amtsgericht Charlottenburg,
> HRB 144331 B
> 
> --
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development