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
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
