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