[Development] Raising the minimum to C++20

[Ahmad Samir]

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 answer
was "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 at 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.macieira at 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 at qt-project.org
> https://lists.qt-project.org/listinfo/development
> 
> --
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
> 
> 

-- 
Ahmad Samir

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <http://lists.qt-project.org/pipermail/development/attachments/20240209/89648bb4/attachment-0001.sig>