[Development] QString and related changes for Qt 6

[André Pönitz]

On Tue, May 12, 2020 at 02:09:21PM -0700, Thiago Macieira 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.
> 
> [Good regexp example snipped]
> 
> I want rules that determine what the API should be without looking at the 
> implementation of those two functions.

Same for me.

And I think this is an important point, even to the degree that a clear, uniform
API is more worth than a handful cycles.

Most of API changes that are currently discussed or even done "for performance
reasons" *do not matter in practice*.

If a real world Qt application has a performance problem, this is *not* solved
by changing QRegularExpression::pattern() from returning a QString to returning
QStringView.

There are very few cases in repeatedly used low level functions where it actually
*does* make sense, but there it's actually ok to have duplicated interface.

The "overload" problem would also be solvable, by not using overloads, but
differently named functions, e.g. by sth like  .midView() instead of .mid().

Andre'