[Development] About the timeline and phases to support C++20 with and in Qt

[Volker Hilsheimer]

> On 3 May 2023, at 19:20, Thiago Macieira <thiago.macieira at intel.com> wrote:
> On Wednesday, 3 May 2023 08:56:07 PDT Volker Hilsheimer via Development wrote:
>> However, C++23 adds a bunch of improvements, and perhaps it’s a much smaller
>> challenge for compiler vendors to support after C++20. If we stick to the
>> timeline of making a disruptive C++ version move with Qt 6.9 in H1/2025,
>> then perhaps we should skip C++20 and immediately require C++23. People
>> that can move to a C++20 toolchain in 2025 can perhaps just as well move to
>> a C++23 toolchain at that point. That needs more investigation, of course.
>> But given the inevitable pain that comes with changing minimum
>> requirements, moving to a standard that is already 5 years old seems a bit
>> wasteful.
> 
> My opinion on C++23 reasonable features we'd like to use without workarounds:
> * if consteval - not supported by current MSVC
> * deducing this - not supported by any current compiler
> * [[assume]] - we could use this now, https://codereview.qt-project.org/462807
> * <expected> - requires GCC 13 or LLVM libc++ 16
> 
> So my opinion is that aiming for C++23 is not possible for 6.9. For a release 
> in March 2025, the interesting features are too recently supported or can be 
> used without C++23 in the first place. The same goes for the next set of 
> features from C++20 I'd like us to explore (<format> with GCC 13; 
> std::source_location with libc++ 16, etc.). At best, we'd have the exact same 
> feature set I proposed for C++20, except we'd compile with -std=c++23.
> 
> So, no, I think we should aim for the feature set I posted yesterday from 
> C++20. The question is only when.



My thinking and assumption is: those users that don't upgrade their toolchain to something recent are also (typically) the users that stay on the latest LTS release. That will be Qt 6.8; what we do in 6.9 and 6.10 and until 6.11 LTS is of limited interest to those users. The C++ standard is just one aspect to this.

But those that can and do upgrade their toolchain regularly might just as well upgrade to something fairly recent whenever they do that. Between 6.8 branching (the last LTS only requiring C++17, as per current plan) and 6.11 (the next LTS after that, if we stick to the current cadence), we and compiler vendors have another 18 months to work on the C++23 feature set. Why would we not want to start using some C++23 features with 6.11 (in H1/26, presumably)? Even if it’s only a subset of the standard - what we document is the compiler versions we support, and we have to limit ourselves mostly to the common denominator anyway.

For non-LTS releases (or the first after the LTS, i.e. 6.9), we might want to bump the minimum compiler versions to something that's not older than 18 months (we can argue over that), and we stick to those versions until the following LTS release, one year later. And assuming that by H1/2025 there is a common subset of the C++23 standard that all compilers support, why would we not use those features?

Volker