Impact of C++20 constinit on our code

C++20 added the constinit keyword. It's one of the few easily-adoptable features in C++20 (meaning you can just place it behind a macro and it's useful if just a single platform supports it, like Q_NULLPTR or Q_CONSTEXPR or Q_DECL_EQ_DELETE).

While the macro is readily added, the real challenge will be to roll it out over the code base.

The acceptance criteria, ideally, would be that for any static or thread_local storage-duration object in our libraries, exactly one of the following is true:

• it's constexpr
• otherwise, it's Q_CONSTINIT const (not 100% identical to constexpr)
• otherwise, it's Q_CONSTINIT (= no dynamic initialisation)
• otherwise, if possible, fix it so it can be any of the above,
• otherwise, it's const (code comment required to explain why it's dynamically-initialized)
• otherwise, it's non-const (code comment required to explain why it's dynamically-initialized)

Reaching this will likely require some form of static analysis support.

The benefit is that constexpr and constinit both guarantee that no runtime initialisation happens, which directly translates into faster program startup.

As a drive-by. for non-constexpr, non-const objects, try to reach zero-initialisation, which has the orthogonal benefit that the object can be stored in the BSS segment (which doesn't take up space in the executable), as opposed to the DATA segment (which does).

Given limited bandwidth, we should at least target to get this programme completed in qtbase and qtdeclarative.