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 _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development