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.dang...@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
smime.p7s
Description: Firma crittografica S/MIME
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
