QtCS2024 C++20
C++ adoption driven by
- QTBUG-109360 (Phase 1) (things we can do today w/o requiring C++20 to build Qt
- QTBUG-109361 (Phase 2) (requires C++20 to build Qt but not Qt users)
- QTBUG-109362 (Phase 3) (requires developers and users of Qt to use C++20)
Notes
There are many APIs that we can use from C++20 without having to require it (constinit, <version>, attributes, spaceship operator, relaxed constexpr, etc.)
There are still too many customers that cannot or do not want to make the move to a C++20-supporting compiler. There is little upside for them to make the change and a large associated cost, due to validation/audit.
What value have we perceived in using C++20 for our own applications? If we don't perceive a value, how do we justify it to our users? Qt Company survey is that customers have not perceived any value yet.
Possible benefits:
- Coroutines: QCoro has been a great help for KDE developers. Implementation could be better if it were tied into QtCore. In particular, it would make using it in public API more acceptable for other frameworks (KF6 Plasma, etc.)
- Heterogeneous QHash lookups: only implemented using concepts, but have a change to implement it with std::enable_if
- std::timezone
We can't use them ourselves inside Qt because we will need to keep Qt compiling with C++17 for the foreseeable future.
Can we require C++20 in some platforms? (Phase I.5)
- Use C++20 in compilers known to support it (e.g., all desktops, some embedded Linux)
- Different from Phase II where Qt itself would require C++20, which would allow us to use those features everywhere
- But would allow use of C++20 in platform-specific code
- QtWebengine requires C++20, but it's also platform-specific
Would Qt accept contributions that backport certain features back to C++17 (assuming BC):
- Maybe, depending on maintenance cost
We need to test C++20 more, like std::ranges on our containers and such. Header checks don't suffice for template classes.