On 11.06.24 21:08, Giuseppe D'Angelo via Development wrote: > Il 11/06/24 07:12, Thiago Macieira ha scritto: [...] > > I'd like to know how much breakage this solution or mine would imply.
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)? [...] > Yet, breaking a ~20 year behavior in "low-level code" is ... scary? It > should require extraordinary motivation and care; we're probably talking > about making 6.8->6.14 warn if someone passes a non-ASCII char to > QASV/QChar(char)'s constructor, and change behavior to accept ASCII-only > in 6.15? I don't want to break _any_ code. I could live with QAnyStringView(char) being deprecated before a future QT_NO_CAST_FROM_CHAR becomes the default, and demands users to pick between u8 (come C++20) and _L1 (and use std::byte for binary¹). But _if_, until then, we want to _be_ consistent, incl. between C++17 and C++20 builds, btw, then statistics say that you will have fewer users of the relatively-recent QASV(char) API than the other APIs, incl. the important group of users still on Qt 5, so the path of least risk is "clearly" fixing QAnyStringView, is it not? Esp. if we pick the fix back to 6.5 or at least 6.8. Thanks, Marc ¹ It's actually the latter I'm more worried about. I'm pretty sure that we can adapt the existing Clazy check for QString(const char*) to suggest _L1 or u8, depending on content, instead. But figuring out whether a QByteArray constructed from char[] is meant to be binary or UTF-8 (or L1, for that matter) is nothing a tool can do. -- Marc Mutz <marc.m...@qt.io> (he/his) Principal Software Engineer The Qt Company Erich-Thilo-Str. 10 12489 Berlin, Germany www.qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
