[Development] Proposal: Deprecate QVector in Qt 6

[Aleix Pol]

On Wed, May 20, 2020 at 3:12 PM Lars Knoll <lars.knoll at 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.Hausmann at 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