[Development] Oslo, we have a problem</apollo 13> [char8_t]

[Mutz, Marc]

On 2019-07-08 04:43, Thiago Macieira wrote:
> On Sunday, 7 July 2019 23:26:40 -03 Konstantin Ritt wrote:
>> As we have string views now, I'd vote for deprecating the string
>> manipulation methods in QByteArray. I doubt we could make QByteArray a 
>> true
>> vector of bytes now, without breaking lots of the user code, but that 
>> could
>> be a good first step.
> 
> We don't have any good 8-bit string manipulation functions outside of
> QByteArray. They stay.
> 
> The question is whether the Latin1 methods (toUpper(), toLower() and 
> the free
> function qstricmp) should be moved or removed. Those would work really 
> well in
> QLatin1String, but QLatin1String is a view, since it doesn't own the 
> data.
> QLatin1String::toUpper() could return a QByteArray...

What I think when I read this is:

Backed by const char*, never implicit:
- QLatin1String - owner of L1 data [change from today, but not a 
breaking one]
- QLatin1StringView - what QLatin1String is now [requires porting, but 
it's just s/QLatin1String/QLatin1StringView/g in client code]

Backed by const char8_t*, implicit:
- QUtf8String - owner of UTF-8 data
- QUtf8StringView - view over UTF-8 data

Backed by const char16_t*, implicit (from char16_t*, Q*StringView, NOT 
from QByteArray)
- QString - owner of UTF-16 data  [as before, possibly using char16_t 
internally to avoid the tons of ushort casts]
- QStringView - view over UTF-16 data

Backed by const std::byte*, implicit:
- QByteArray - owner of std::byte data, no string-like functions 
[breaking change, but anyway far in the future, as we can't depend on 
std::byte, yet]
- QByteArrayView - view over std::byte (uchar, char, ...) data.

QByteArray, QUtf8String and QLatin1String(new) could use the same 
backend, for zero-copy transformations between them.

Is this a realistic goal for Qt 7? Last time I proposed 
QUtf8String/View, it's usefulness was challenged. I think the advent of 
char8_t in C++20 and std::byte in C++17 change the game quite a bit, 
though.

I'm also looking at all the relational operators we have between our 
string-like classes, and it's ... frightening. Using views to define 
relations would allow to cut quite a lot of relational operator 
overloads.

Thanks,
Marc