Initiative: Qt and C++20

There are three broad categories of this:

• First and foremost, I would like my projects to compile in C++20 mode and not have Qt headers get in the way in any way. That means C++20 warnings and compile errors should be fixed at the very least in public and then private headers, but eventually also in the implementation.
• Second, I would like Qt APIs to better interoperate with their std C++ counterparts. A successful example is making QMutexLocker a template and QMutex a Lockable, so that now I can use QMutexLocker on a std::mutex as well as a std::unique_lock on a QMutex. A less successful example is requiring UTF-8 for const char* strings, but then not supporting u8"" in your APIs in C++20 mode.
• Third, and this ties in with the second point somewhat, I'd like Qt to adopt new C++20 features. A good example here is QUtf8StringView, which essentially fixes the C++20 u8"" vs. const char * problem, if only you would use it in the API more. A less successful example is QFuture, which still isn't {{co_await}}able.

This list is broadly in priority order.

These issues are but a small subset of the problems. I've made this epic to track all the different issues that are necessary to make Qt 6 work well with C++20. I think, too, that Qt 5.15 should at least not get in the way when we use it in C++20 projects.

The following C++20 language features don't seem to have any effect on Qt's implementation or APIs, so they haven't gotten their own epic (yet):

• "using enum" (defined(__cpp_using_enum), https://en.cppreference.com/w/cpp/language/enum#Using-enum-declaration)
• Efficient sized delete for variable sized classes" (defined(__cpp_impl_destroying_delete) && defined(__cpp_lib_destroying_delete), aka. std::destroying_delete, https://wg21.link/P0722)
  • though maybe this is interesting for our container implementations, cf. https://wg21.link/P0722R1
• "When are constexpr functions defined?" (defined(__cpp_constexpr_in_decltype), https://wg21.link/P0859)
• "signed integers are two's complement" (https://wg21.link/P1236R1): Qt already required that
• "init-statements for range-based for" (https://wg21.link/P0614)
  • will allow #define Q_FOREACH(x, y) for (const auto _c = y; x : _c) and finally do the transformation in a automatable manner
• "ADL and function templates that are not visible" (https://wg21.link/P0846)
  • though this fully enables the magic get() for the Tuple Protocol (used for SB), cf. e.g. QPoint's implementation
  • before, at least one non-hidden-friend template named get() would have to be in scope, this is no longer necessary)
  • We have since added QT_ENABLE_P0846_SEMANTICS_FOR, because we needed this for get/get_if to QVariant
• "make typename more optional" (https://wg21.link/P0634)
• "integrating feature-test-macros" (https://wg21.link/P0941R2)
  • though we might want to start using <version> as soon as we can (QTBUG-108228)
• "nested inline namespaces" (https://wg21.link/P1094R2): we can just use separate lines
• some changes to SB (https://wg21.link/P1091, https://wg21.link/P1381): SBs are not API

The following C++20 library features don't seem to have any effect on Qt's implementation or APIs, so they haven't gotten their own epic (yet):

• erase_if (defined(__cpp_lib_erase_if) && __cpp_lib_erase_if >= 202002, https://wg21.link/P1973, https://wg21.link/P1115): we already implement our own overloads of these functions according to the latest standard version
• <bit> (defined(__cpp_lib_bit_ops), https://wg21.link/P0553 / defined(__cpp_lib_int_pow2), https://wg21.link/P0556, https://wg21.link/P1956): these functions have a certain overlap with our <QtAlgorithms> header, and, indeed, are already used in these. There were a few hickups because the <bit> functions treat pathological input differently from our traditional functions, but these were fixed AFAIR.
• Smart pointer creation with default initialization (defined(__cpp_lib_smart_ptr_for_overwrite), https://wg21.link/P1020, https://wg21.link/P1973): Can't use, can't reimplement for internal use (q20), because it needs stdlib support
  • except std::make_unique_for_overwrite, which may make sense to implement in q20
• Constexpr for <numeric> (defined(__cpp_lib_constexpr_numeric), https://wg21.link/P1645)

Acceptance criteria for this epic: all the issues linked to it are fixed (or closed or re-linked to C++23).