[Development] QString and related changes for Qt 6

[Tor Arne Vestbø]

> 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.

Tor Arne