[Development] QString and related changes for Qt 6

[Иван Комиссаров]

> 12 мая 2020 г., в 09:49, Lars Knoll <lars.knoll at qt.io> написал(а):
> 
> Hi all,
> 

First of all, the plan sounds great!

> 
> Most other classes:
> 
> * Only take and return QString
> * Exceptions can be done where significant performance gains can be demonstrated and the API will by design not require a copy of the data (e.g. XML writer, stream writers, date time handling)

Let me disagree here. The decision should be taken on the fact if the object takes ownership of the string (and thus QString is used) or it only «looks» into it.

Otherwise, QString gets propagated all over the place:

void addSuffix(const QString &suffiix) // can’t use view here!
{
    m_memberString.append(suffix); // no QStringView overload, can’t use QStringView in the API
}

Ok, we aim to have an QString::append(QStringView) overload, so the example is not that good.

Another one:

QMimeType findMimeType(const QString &name) // can’t use view here!
{
    QMimeDataBase().mimeTypeForName(name); // no QStringView overload, the API propagates QString through all the code
}

I hope the idea is clear.

PS: it is not that easy to fix QMimeDataBase to take QStringView (I looked into the possibility), but the aim should be to take QStringView where it is possible, not where it is *faster*.

Ivan