[Development] QString and related changes for Qt 6

Ville Voutilainen ville.voutilainen at gmail.com
Wed May 13 12:06:11 CEST 2020

On Wed, 13 May 2020 at 12:50, Tor Arne Vestbø <Tor.arne.Vestbo at qt.io> wrote:
> > On 13 May 2020, at 10:12, Edward Welbourne <edward.welbourne at 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.

More information about the Development mailing list