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

[Thiago Macieira]

On Wednesday, 3 May 2023 08:56:07 PDT Volker Hilsheimer via Development wrote:
> The standing proposal is to move to C++20 with Qt 6.9, after the next LTS
> release. I see no pressing reasons to accelerate that. The value of the
> features Thiago listed - which excludes all the big stuff anyway - doesn’t
> seem so significant that it outweighs the impact on the community of users
> that are stuck on C++17, for a variety of reasons that we can’t just shrug
> off.

The big stuff you're talking about are Modules and co-routines. I don't see us 
adopting Modules any time soon, not even for the 6.9 release. It's not well 
supported *today*. Co-routines we'd need to learn how to make good use of them 
and we won't until we begin using them, so postponing buys us little.

That leaves concepts, which I think we could begin rolling in slowly. 
According to https://en.cppreference.com/w/cpp/20, the core language support 
appears to be there for the compilers versions I called out for, but not the 
concepts library for libc++. Upping the requirement for libc++ might be an 
acceptable compromise once we learn what we want to do with concepts.

> 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.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5152 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20230503/f7569f00/attachment-0001.bin>