[Development] QString and related changes for Qt 6
Tor Arne Vestbø
Tor.arne.Vestbo at qt.io
Wed May 13 11:43:54 CEST 2020
> 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:
Or if the allocations and conversations are really a performance issue for this particular piece of code:
Anything else should be reserved for corner cases where the explicitness is warranted.
More information about the Development