On Wed, May 20, 2020 at 3:12 PM Lars Knoll <lars.kn...@qt.io> wrote: > > It’s been a while since Simon started this thread. I’m sure some people will > disagree, no matter what we do. But I’d like to conclude it, so we have one > solution for Qt 6. > > My focus is on reducing migration pain for our users and ourselves (we’ve got > more than enough things to finish…), as well as consistency in naming within > Qt. > > Here’s what we will do: > > * QList and QVector are aliases for each other > * We make QList the main type, and QVector an alias to it > * We keep both names, QList and QVector. None of them is deprecated > * In Qt (code and documentation) we use QList for function arguments and > return types > * QStringList is an alias to QList<QString>, ditto for QByteArrayList > * We can extend/specialize QList for certain types through QListSpecialMethods > > Like that we can minimise changes in our public API between Qt 5 and Qt 6 (no > mass renaming from QList to QVector) and don’t have naming inconsistencies > with QStringList and QByteArrayList or how many of our functions are named. > > This is the pragmatic solution to avoid adding more pain to our users. And if > some of our users prefer using QVector as the name in their code, they can do > that without problems. > > I don’t think it’s a problem from an advertisement point of view neither (… > QList is bad, because …), as we can now simply say that we’ve fixed it for Qt > 6, and both QList and QVector can be used as the class name. > > And now I’ll get some Popcorn for the inevitable bike-shedding that’s going > to happen anyway :) > > Cheers, > Lars > > On 23 Apr 2020, at 09:43, Simon Hausmann <simon.hausm...@qt.io> wrote: > > Hi, > > In dev we've had QVector being an alias for QList for a while now. For the > 6.0 release this particular topic (QList/QVector) suggests two goals (among > others): > > (1) Use the same type throughout the public API of Qt. > > (2) Make it easy for our users to maintain a code base that works with Qt > 5 and 6. > > > In the light of those two goals, I think we should keep using QList as the > type in the public API. I don't think we should do a search and replace > activity and switch to QVector. In the light of that, I would like to propose > simply deprecating QVector and stick to QList everywhere. > > > What do you think?
From a Qt usage perspective I'm really happy with this conclusion. Deprecating either class was a massive change on our codebases (both upstream Qt as well as KDE's as a Qt user and I assume every other product that uses Qt). Knowing that accepting a patch today that uses either will be good is peace of mind. It even resolves the QStringList change quite elegantly. :) Thanks! Aleix _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
