On 15.11.22 03:32, Giuseppe D'Angelo via Development wrote: > > We've found a robust solution to this problem via the removed_api > mechanism, which is going to keep the QString overload, but hide it from > clients. (At least, I *think*.) This will make calls passing u"" > literals to keep working just fine. So what other concern is there for > not allowing this QString construction?
The problem is that replacing a QString function with a QStringView one is highly SiC. This has nothing to do with char16_t literals, but more with char8_t (and char) literals from which QString implicitly converts, but QStringView does not. This is why we never replaced, but always overloaded, QString functions with QStringView ones in Qt 5. The Qt 6 solution is to replace QString functions with QAnyStringView, which is designed to replace an overload set consisting of - QString - QChar - QStringView - QUtfStringView (incl. char and char8_t literals) - QLatin1StringView - QByteArrayView (only for compat, to be subsumed by QUtf8StringView) with a single function in an SC way. Unless and until we replace all QString/QStringView overload sets with a single QAnyStringView function (possibly accompanied by a QString Q_WEAK_OVERLOAD), we can't make QString implicitly convertible from char16_t literals. While we can QT_REMOVED_SINCE our own API, we can't do the same for user API that relies on the explicit guarantee of QString/QStringView overloadability. Thanks, Marc -- Marc Mutz <marc.m...@qt.io> 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
