[Development] Proposal: Deprecate QVector in Qt 6

[Jason H]

> Sent: Thursday, April 23, 2020 at 12:05 PM
> From: "Giuseppe D'Angelo via Development" <development at qt-project.org>
> To: development at qt-project.org
> Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6
>
> On 4/23/20 5:04 PM, Julius Bullinger wrote:
> > Another suggestion: Get rid if the aliases; use the fully-qualified
> > types instead.
> >
> > I'm always irritated if I open the documentation of QVariantList from
> > within Qt Creator, and land on the QVariant docu instead. I'm interested
> > in the features of the container, not the contained type.
>
> This is a documentation bug or a Creator bug. You're supposed to land on
> this anchor: https://doc.qt.io/qt-5/qvariant.html#QVariantList-typedef
>
> > And I have to remember if QStringList is the same as as QList<QString>,
> > or if it's actually a different container with a different API.
>
> In fact, it is-a QList<QString>. What's the problem here with its naming?


Because I can't QSringList{"me", "you"}.join() with a QList.

Thinking outsize of the box...
It seems that all this is cause d by someone wanting to store a pointer to an item in QVector, which may be reallocted and therfore have moved.
It seem then that the only thing to do is to use a traditional QList, or return only some kind of ref which will be a stable reference to the item.
QStableRef r9 = vector[9];
vector.resize()
// r9 is updated during resize() and still points to that it was meant to.
It's not good practice to store a ref to something that can be realloated. I don't know how you can prevent people from doing that with offering T& operator[](int i);