On Wed, 13 May 2020 at 12:50, Tor Arne Vestbø <tor.arne.ves...@qt.io> wrote: > > > > > 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.
That's all well and good, but if foo.bar(a) and foo.bar(b) have different semantics on whether the class copies or views what I pass in, I am going to hurt you. :) Meaning that if it sometimes stores a copy, then it should always store a copy, instead of sometimes storing a copy and sometimes storing a view, in which case I need to be insanely careful about calling such functionality. If the class doesn't store the argument, I don't care. If it does, it should decide whether it stores a copy or a view. Overloads in an overload set should have the same semantics, otherwise that API is a vector<bool>, where for some incoming types it does A and for others it does B, and the code can no longer be read without looking at the API documentation for every call. _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development