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
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
