Qt Contributors Summit 2022 - Program/C++20 in Qt

Session Summary

We already had some discussion about usage of C++20 types in our ABI (see https://lists.qt-project.org/pipermail/development/2022-January/042151.html). However, there are still further things that we should discuss:

• Are there non-ABI impacting changes that we should do? E.g. marking classes as views/ranges, supporting new std types where necessary, etc.
• How should our testing story look like for C++20? Currently, we only have one gcc build for C++20 in our CI
• Do we want to mandate C++20 during the lifetime of Qt 6 at some point? Can we (think of embedded platforms)?
• C++ modules and CMake? How will it impact us?

Session Owners

• Fabian Kosmale, Marc Mutz

Notes

(Taken by Joerg)

Should we switch to C++20 wholesale? We need to make sure users can use cpp20. Then, we should add benefits for users of cpp20. We switched to cpp11 in 2016. That was when cpp14 was out. We could switch to cpp20 after cpp23 is out. Proposal: we would like to switch in Qt 6.6. We need to check all supported toolchains for support.

Difference to the switch to cpp11 is that we would use the cpp20 features behind API boundaries. There's no easy way of guarding cpp20 features. What are the new features of the core language we want to use?

modules, coroutines, ... are features that only make sense if we go all in. Having a module and non-module build doesn't fly.

Modules: maybe we have to wait for Qt7. We should explore already to be able to influence the direction of upstream.

QDateTime could benefit, but that's rather limited.

For example coroutines: to use them one would build Qt with cpp20 and use the API from cpp17 through wrappers.

std::format - do we want to have a Qt equivalent? We could have an impl. optimized for utf16 strings. Questionable if this should replace stringtokenizer.

Should we add spaceship op to all types that have the full set of ops? Conclusion seems to be: yes. We need to have both for now, we cannot remove the old ops. Should be done ASAP.

Where we use timeouts as ints in API we should use durations. QDeadlineTimer should construct implicitly from std::chrono::duration so you can just pass 1s.

poll results: I haven't used cpp20 so far 80% I used it and ran into compiler issues 10% I used it and love it 20%

Quite some library features are not there yet across all platforms, for example std::filesystem. At the time we get to Qt 6.6 situation might be better. But switching after an LTS release might be the right thing to do.

Can we add cpp20 support for some platforms only? Additional workload for us shouldn't be too bad. Famous last words. Binary packages should be built with C++20.

Beware: gcc's cpp20 ABI is not guaranteed to be stable at the moment. We have no way of checking for experimental API. Our BC promise holds only when then toolchain does not change though. Still, it's a problem for binary packages.

We will discuss some more on the mailing list.