On 9/2/24 16:45, Volker Hilsheimer via Development wrote:
I haven’t heard any convincing argument for us raising the minimum to C++ 20 in the foreseeable future. Not for building Qt, and not for using Qt.At most we get some convenience constructs for ourselves. There’s value in that, of course. But unless I miss something huge, then that value is quite small. We have a working implementation of e.g. atomics that is sufficient for our own needs; we have our own implementation of <bit>. We now also have QSpan, which we practically don’t use anywhere in Qt so far. And that value is of practically no relevance to users of Qt - they can use C++20 in their application, together with Qt. The 3 big C++20 features people ask us about are modules, co-routines, and concepts. We have no compelling answers here. You can’t build Qt into a set of modules; we have no APIs using co-routines; none of our template constraints are expressed, or at least documented, as concepts, and there is no draft of a concept library for things that might be interesting for Qt users. Do we really want to go out and say that C++20 is now mandatory to build or use Qt, while we have no convincing story on any of that? Do we want to ask people to make a significant investment if they want to work with the latest Qt version, but even then they don’t get any support for any of the big three features? So, as much as I’d like for some of the things I’m working on to be able to benefit from C++ 20, I’d also say that we should rather slow down, and only require C++20 if we have something to show for it. We can perhaps still make improvements to better enable C++20 features, such as std::ranges, in application code; but that should neither require Qt to be built with C++20, nor require applications that don’t use std::ranges to use C++20. Volker
The way KDE Frameworks and Plasma have raised the minimum required C++ version was asking distributions "do you have a problem if we require C++17?" and the answerwas "we have recent enough gcc/clang, so go ahead if you want", so Plasma 5 and KF5 raised the minimum required to C++17 during the lifetime of KF5 (with the caveat, IIRC, of not using C++17-only headers unconditionally in public header files). Last time I checked, Plasma 6.0 now requires C++20, using the same process outlined above.
I wonder if this can be done here too. Can you survey Linux distro developers/maintainers, your customers and other point-of-contacts? This way you will have a clearer picture of the situation, and can make an informed decision.
For example I've started compiling with C++20 locally about 4-5 months ago, the CI still uses C++17, I have seen very few issues.
My 2p's. Regards, Ahmad Samir
On 9 Feb 2024, at 10:41, Vladimir Minenko via Development <development@qt-project.org> wrote: Just as a reminder, the "C++20 is mandatory for users of Qt (Phase III)” (https://bugreports.qt.io/browse/QTBUG-109362) says "The tentative plan is Qt 6.12+” and "C++20 is required for the development and buiding of Qt itself (Phase II)” (https://bugreports.qt.io/browse/QTBUG-109361) - "The tentative plan is Qt 6.9-6.11” With all the respect to the power of C++20 and enthusiasm to use it from Qt Project developers, what should we expect from all other users if we would make this change in 6.8, considering: a) just 4 months left to the Feature Freeze for 6.8 b) there is zero communication to users beyond the above issues on Qt But Reports and discussions on this mailing list (which is actually for Qt developers and not Qt users, BTW) c) there is no other communication about the done and ongoing works introducing C++20 in Qt and plans for future versions, beyond the talk from Mark at QtWS22 and careful reading of “What’s New” pages Qt crashed such a change on users with C++11 and with C++17 in the past. Each time after this, there were much more negative responses than “thank you”s. I still hope we find a way to do this better this time. And just “faster” is not “better" In the current shape, my vote is “no”. -- Vladimir On 3. Feb 2024, at 18:15, Thiago Macieira <thiago.macie...@intel.com> wrote: On Tuesday, 2 May 2023 17:39:01 PST Thiago Macieira wrote: 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. What's the current state for those, for supporting Qt 6.8 or 6.9? We have VxWorks coming in and I'd like it to meet a higher minimum bar than "legacy". That is, I'd like VxWorks to require a C++20-compliant compiler before being enabled in our CI, but that's only fair if we have a line-of- sight to bringing everyone to C++20. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
-- Ahmad Samir
OpenPGP_signature
Description: OpenPGP digital signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
