> On 12 May 2020, at 23:09, Thiago Macieira <thiago.macie...@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
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
