[Development] Are char literals L1 or U8 in Qt?

[Thiago Macieira]

On Monday 10 June 2024 21:51:21 GMT-7 Marc Mutz via Development wrote:
> - change `char` to be consistently U8 (in case it wasn't obvious, this
>    _silently_ breaks (probably large amounts of) existing code - _now_,
>    independent on the second step here (keep behaviour or also phase out
>    char))

I'm arguing that such code is likely already broken (producing mojibake) for 
non-US-ASCII content, so having U+FFFD instead of mojibake is not worse. You 
wouldn't be able to work around the issue by un-doing the improper encoding, 
which means it would force users to fix their code.

Not all code is already broken. For example, if you are iterating over a 
QLatin1StringView, you could be comparing QChar to char, which probably 
implies an implicit conversion through that constructor.

If we tried to remove the constructor, then the char16_t constructor would 
probably get used and produce the same effect.

So, I don't have a solution. It just strikes me as wrong to perpetuate what 
appears to have been a wrong decision,

> Or, fourth option: We can merge a patch (still to 6.8) that warns (or
> even fails to compile) if a user uses QASV(char), even outside
> QT_NO_CAST_FROM_ASCII, telling them to use char16_t or QLatin1Char
> instead, and then fix the behaviour in Qt 6.9, or even keep it as a
> first step toward Qt 7 behaviour (though I'd like to keep a port from a
> string-ish overload set to QASV source-compatible; it was a lot of work
> to get there).

We're talking 6.9 at this point.

I'd like to know how much breakage this solution or mine would imply.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Principal Engineer - Intel DCAI Fleet Systems Engineering
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5152 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20240610/e9328b96/attachment.bin>