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