[Development] QAnyStringView

[Marc Mutz]

On 2020-06-24 09:32, Marc Mutz via Development wrote:
[...]
>>> 2) the complexity is already there and QAnyStringView helps in 
>>> reducing
>>> it:
>>> 
>>>    https://codereview.qt-project.org/c/qt/qtbase/+/303483 (QCalendar)
>>>    https://codereview.qt-project.org/c/qt/qtbase/+/303512 (QColor)
>>>    https://codereview.qt-project.org/c/qt/qtbase/+/303707 (arg())
>>>    https://codereview.qt-project.org/c/qt/qtbase/+/303708 (QUuid)

I should note that apart from the above, I'm aware of the following 
QtBase APIs outside string classes that would require porting to 
QAnyStringView:

- https://codereview.qt-project.org/c/qt/qtbase/+/305402 
(QVersionNumber)
- QtJSON (no idea what the status of this is - will it be removed?)
- QCbor (possibly; no idea what it is, except something like QtJSON)
- QDate/Time/QLocale format strings and number parsing
- QXmlStream
- QTextStream / QDataStream
- QtTest (compare functions)

That's not too much.

We also need to come up with a strategy for storing Q*View in QVariant, 
like QLatin1String.

We have several other APIs that would benefit from QAnyStringView:

- QObject::setObjectName() - almost exclusively passed literals
- QRegularExpression's pattern - ditto, and pattern is compiled into 
code anyway
- QSettings
- QUrl/Query, Network headers
- possibly QFont::fromString(), but that one is just weird (not a static 
function)
- any fromString() and lookup APIs elsewhere in Qt

These are just off the top of my head. There's probably more.

Another, much more complicated issue (but we have that now) is hashing. 
We have mixed-type equality, but the hash functions don't agree. This is 
pre-existing, but a variant string type exacerbates the issue. The only 
fix atm is to = delete qHash(QAnyStringView) because it's not 
meaningfully (ie. consistently) implementable.

Thanks,
Marc