[Development] How qAsConst and qExchange lead to qNN

[Marc Mutz]

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.mutz at 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