[Development] How qAsConst and qExchange lead to qNN
marc.mutz at qt.io
Tue Nov 15 08:52:23 CET 2022
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
- QUtfStringView (incl. char and char8_t literals)
- 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
Marc Mutz <marc.mutz at qt.io>
Principal Software Engineer
The Qt Company
Erich-Thilo-Str. 10 12489
Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B
More information about the Development