[Development] QString and related changes for Qt 6

[Thiago Macieira]

On Tuesday, 12 May 2020 10:48:24 PDT Giuseppe D'Angelo via Development wrote:
> What do you do? Adding a QStringView overload will make calls ambiguous,
> removing the QString one will be an ABI break. We need an established
> solution for these cases as they'll pop up during the Qt 6 lifetime.

Indeed.

And the API policy must be one such that it doesn't depend on what the method 
does *today* and it doesn't create a mess. Functions change.

Let's take an example with QRegularExpression's pattern (not picking on 
Giuseppe). Today it is:

    QString pattern() const;
    void setPattern(const QString &pattern);

QString QRegularExpression::pattern() const
{
    return d->pattern;
}

Since this is returning a stored QString, someone might feel that it should 
instead return a QStringView. But if it's storing, then the setter should 
remain const QString &. That would be:

    QStringView pattern() const;
    void setPattern(const QString &pattern);

But suppose that there's a pcre2_get_pattern_16() function. Then someone might 
be tempted to say that since PCRE stores the pattern, we don't need to. That 
would mean QRegularExpression::pattern() ought to be written as:

QString QRegularExpression::pattern() const
{
    qsizetype len = pcre2_get_pattern_length_16(d->compiledPattern);
    QString retval(Qt::Uninitialized, len);
    pcre2_get_pattern_16(d->compiledPattern, retval.data(), len);
    return retval;
}

But if PCRE is going to store the pattern and PCRE doesn't use QString, then 
setPattern could take a QStringView instead. That would be:

    QString pattern() const;
    void setPattern(QStringView pattern);

That's the opposite of the previous one.

I want rules that determine what the API should be without looking at the 
implementation of those two functions.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products