> On 13 May 2020, at 10:12, Edward Welbourne <edward.welbou...@qt.io> wrote: > >> Note that adding the QString(char16_t*) constructor introduces this >> ambiguity for the functions that are already overloaded on >> QString+QStringView (and thus today are using QStringView). > > Would it suffice to skip the QString(char16_t *) constructor and, > instead, have a QString(QStringView) constructor ? > > I guess calls to functions taking QString would have to make one of the > steps explicit, when passing a u"...", i.e. either call > f(QString(u"...")) or f(QStringView(u"...")), preferring the latter (as > it's future-proof against f changing signature from QString to > QStingView later; note that this concern applies to Qt-using code, which > may allow itself such ABI-breaks, not just Qt itself, which wouldn't, at > least not once the old API has appeared in a public release). I suppose > both forms are capable of exploiting constexpr and happening at > compile-time, when the compiler deigns to make it so.
Whatever we end up with, _please_ avoid the explicitness/verboseness/boilerplate of having to wrap every “foo” in some QPreferredStringTypeOfTheWeek(“foo”) I expect my code to looks like this: foo.bar(“baz”) Or if the allocations and conversations are really a performance issue for this particular piece of code: foo.bar(u“baz”) Anything else should be reserved for corner cases where the explicitness is warranted. Tor Arne _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
