[Development] QString and related changes for Qt 6

Lars Knoll lars.knoll at qt.io
Wed May 13 08:33:51 CEST 2020


> On 12 May 2020, at 23:09, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
> 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.

This is one reason why I think we should simply use QString in most of those cases. 

Additionally, QString is a class that owns it’s data, making it the class that’s easiest to use and safest. QStringView doesn’t own it’s data and as such there are always lifetime considerations that need to be taken into account when using it. So using it would make using the API harder and more error prone.

Cheers,
Lars



More information about the Development mailing list