[Development] How qAsConst and qExchange lead to qNN

[Giuseppe D'Angelo]

Il 10/11/22 20:27, Thiago Macieira ha scritto:
>> (We end up with these overload sets because right now we have tons of
>> f(QString), and we're slowly moving them to f(QStringView) if it does
>> make sense for them. Due to the BC promise we can't just_remove_
>> f(QString).)
> And we shouldn't. So we shouldn't be moving to QStringView.
> 
> Where it's useful, we can use a Q_WEAK_OVERLOAD. But I insist that we only do
> that where there's a clear performance benefit. Otherwise, keep using QString.

I'm not sure what is meant here. I was just pointing out that 
overloading a function with QString and QStringView (or QAnyStringView 
for that matter) is just a historical accident:

* we have an "old" API that takes QString
* we realize it doesn't _have to_ (e.g. string never stored, etc.)
* we want to replace it with a "newer" API that takes QStringView. We 
can't literally *replace* it (binary, and also, minor, source 
compatibility). So we have to add a QStringView overload and keep both 
for the entire major version.
* Now, if we have a QString(const char16_t *) constructor, this 
overloading break SC when someone calls the API with a u"" literal, and 
that's super-annoying.


But the point is that if we developed the API from scratch today, we'd 
likely not even had the QString overload to begin with -- we would have 
averted the whole issue.

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?



Thanks,

-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4244 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20221115/9d491ef8/attachment-0001.bin>