[Development] QUtf8String{, View} (was: Re: QString and related changes for Qt 6)

[Edward Welbourne]

Thiago Macieira (23 May 2020 03:06) wrote:
> Update:
>
> As we're reviewing the changes Lars is making to get rid of
> QStringRef, Lars, Marc and I came to the conclusion that
> QUtf8StringView is required for Qt 6.0.
[snip]

Sounds sensible.
I would just call it QUtf8View, since (see below) I don't see value in a
separate QUtf8String for it to be a view into, so making clear that it's
a view, not backed by any particular string type, has value; but the
detail of naming is less important.

> There are currently no conclusions on QUtf8String and QAnyString, nor
> on what the APIs should look like.

I don't really see the need for an owning 8-bit string type (hence,
equally, for QAnyString); we have QByteArray to serve as data-owner
behind a UTF-8 view, when the data's not a C-string literal but is known
to be UTF-8, and the simplicity of "when we store bytes with the
semantics of text, we always do so in UTF-16" argues against doing
anything more with UTF-8 views than supporting comparisons (including
starts-with, ends-with, contains, index-of) and constructing a QString
out of one.

The "comparisons" heading might stretch as far as using a UTF-8 key to
do a look-up in a QString-keyed hash, if doing so does actually bring a
meaningful saving compared to converting to UTF-16 first; which, of
course, might resurface in various other query APIs (asking for an HTTP
header's value from an object packaging a map, or an HTML tag's
attribute value).

There are perhaps other places where it'll make sense for APIs taking a
QStringView to also have a QUtf8View overload; but, crucially, by
limiting UTF-8 to view-level support, we provide a bound on how widely
it makes sense to burden our APIs with more overloads than just QString
and/or up to two views.

	Eddy.