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

[Edward Welbourne]

Il 11/06/24 07:12, Thiago Macieira ha scritto:
>> I'd like to know how much breakage this solution or mine would imply.

Marc Mutz (11 June 2024 21:44) replied:
> I may have missed something, but I still can't see what your solution
> is? I've enumerated the options, would you be so kind as to point out
> which one you want (or continue numbering should I have missed an
> option)?

here refering back to:

Marc Mutz (11 June 2024 06:51) enumerated:
>>> AFAICT, we have three options:
>>>
>>> - keep status quo (then all QAnyStringView-taking functions need to
>>>   get a QChar overload, and will probably be ambiguous, so even with
>>>   "status quo", we'd need to change _something_
>>>   O(#functions-using-QASV))
>>> - change `char` to be consistently L1, phase out `char` as a
>>>   character and string type (my proposal; AFAICT, limited impact
>>>   (you can already compile with QT_NO_CAST_FROM_ASCII, even in Qt 5,
>>>   to get very close to the future state; changes limited to QASV:
>>>   only (O(1)))
>>> - 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))

We have a QLatin1Char type.  We could deprecate QASV(char) with the
deprecation warning suggesting overt use of QLatin1Char or u'?'
literals.  I trust those, at least, DTRT.

It makes no sense to read a single char literal as UTF-8, unless it's
ASCII, making the UTF-8-ness irrelevant.  We have historically used
Latin-1 for char, but this is Western-Eurocentric and anything outside
ASCII even there is problematic because either it's misencoded for our
UTF-8 build systems or it's written as an escape that the reader won't
know the meaning of.

	Eddy.