On Thursday, 10 November 2022 10:40:35 PST Giuseppe D'Angelo via Development wrote: > On 09/11/2022 20:25, Thiago Macieira wrote: > > Our API should default to passing QStrings for simplicity and not to > > confuse> > > the user. The fact that I cannot wrote: > > foo(u"bar'); > > > > if foo takes a QString is MESSED UP. > > Is this because we deliberately didn't add a QString(const char16_t *) > constructor, to prevent ambiguities in case we have overloads like these: > > void f(QString) > void f(QStringView) > > ?
I think so. I understand why we did it. I just think it's wrong. > (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. > However: doesn't the new "removed API" system change the status quo? The > point of the new system is to allow us to preserve BC, while always > presenting only one of the two functions (the most recent) to client > code. f(u"foo") would therefore still compile and don't incur in the > ambiguity. > > (Surely, it's not 100% API compatible, but it would be a SIC A). It might, indeed. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
