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

[Mutz, Marc]

On 2019-07-06 14:58, Thiago Macieira wrote:
> On Saturday, 6 July 2019 07:43:39 -03 Mutz, Marc via Development wrote:
>> So, if GCC is right, we have no way of adapting our API to not break 
>> in
>> C++20. So we need to decide what to break:
>> 
>> a) using 0 for nullptr, or
>> b) using u8"Hello" at all
> 
> When discussing with SG16 folks, the idea was that u8"Hello" would be 
> an
> internal, indeterminate type and would cast to either const char8_t[] 
> or const
> char[] depending on the context. In case of no context (i.e., 
> templates, auto)
> or of both choices being available, char8_t wins.
> 
> Is this not how it's implemented?

Apparently not.

> Anyway, QByteArray has *Latin1* text-manipulation functions (toUpper 
> and
> toLower), its split(char) function will happily split on indivdual 
> bytes of an
> UTF-8 multibyte sequence, so adding char8_t overloads seems just wrong 
> to me.

const char* in Qt is always assumed to be UTF-8-encoded. You need to use 
QLatin1String to have it interpreted as Latin-1:

https://doc.qt.io/qt-5/qstring.html#QString-8
https://doc.qt.io/qt-5/qstring.html#QString-7

> What did you try to use QByteArray with that showed problems?

Just QByteArray(u8"Hello") already fails when compiled with -std=c++2a. 
And this is also why we need to fix it. The same compiles fine in C++17, 
and does the expected thing.

Thanks,
Marc