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
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
