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. _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development