[Development] Proposal: Deprecate QVector in Qt 6
André Pönitz
apoenitz at t-online.de
Thu Apr 23 13:45:25 CEST 2020
On Thu, Apr 23, 2020 at 12:48:45PM +0200, Elvis Stansvik wrote:
> Den tors 23 apr. 2020 kl 11:45 skrev Laszlo Agocs <laszlo.agocs at qt.io>:
> >
> > That depends on the number of the functions affected, and how commonly those
> > are used. If we are talking about just a few virtual functions here and there
> > which are not expected to be overriden by a vast majority of applications
> > (such as the QIconEngine example), then changing the signatures is probably
> > acceptable. After all, Qt 6 will have a number of source compatibility breaks
> > (typically in less commonly used APIs) anyways, let's have no illusions here.
> > So on its own this should not be an argument for reprioritizing the tainted
> > QList name.
> >
> > For years we have been teaching people to stay away from QList and treat it as
> > a legacy thing in the API, and that it may change in a future major release.
> > Any newly introduced public APIs (in the graphics-related areas at least) for
> > the past 5-6 years are using QVector. It is odd to turn this over just like
> > that.
>
> I have to agree with Laszlo here. The message has been that QList due to its
> duality etc is problematic and may become deprecated, so we've put in work on
> changing it to QVector in our code bases [...]
Was that work more than s/QList/QVector/ ?
>and used QVector in newly written
> code. It's a bit annoying if QList is now to become the name to be used. I'll
> accept whatever is decided, but think it's a little unfortunate if we'd have to
> change all that code back to QList again.
Andre'
More information about the Development
mailing list