[Development] Raising the minimum to C++20

[Marc Mutz]

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