[Development] Supported compilers for Qt 6

[Mutz, Marc]

On 2019-08-12 22:13, Thiago Macieira wrote:
> On Monday, 12 August 2019 13:03:47 PDT Mutz, Marc via Development 
> wrote:
>> The milestone is std::byte, which which we could put QByteArray on a
>> sound basis. And char8_t, which would make QUtf8String(View) fly.
> 
> QByteArray, due to its dual string / byte array nature, will continue 
> to
> operate on char.

It was a mistake to merge QCString and QByteArray back then. This design 
doesn't work. Python 2 realized it, and we realized it too (toLower() 
interprets as L1, but const char*, and thus, by extension, QByteArray, 
is expected to be utf-8-encoded in Qt source). We had them separate 
before, we can separate them again.

> After all, char *is* a byte.

No, a char is a character. std::byte is a byte.

> We should add the unsigned char
> variants too, though.

Ack.

I'm not saying it's easy to reduce QByteArray to an array of byte, but 
it's a longer-term goal we should strive for. And we can emulate 
std::byte:

    enum class QByte : unsigned char {};

plus C++17 gives us a type that, for all intents and purposes, is a 
std::byte (it's a different type and it has a different name, but it's 
behaviour-compatible, as in: Qt 7 can do s/QByte/std::byte/wg and it 
will work.

> As for char8_t, it's C++20. We're not going to enforce compiling Qt 
> with
> -std=c++2a.

Lars said "and selected C++20 features". char8_t is a game-changer for 
Qt. I don't expect we can depend on it, but this, and the other two 
(std::byte and CTAD) are, from my POV, high amongst the features that 
have the most impact on the Qt API.

Thanks,
Marc