[Development] Proposal: Deprecate QVector in Qt 6

Simon Hausmann Simon.Hausmann at qt.io
Thu Apr 23 10:27:15 CEST 2020

Hi Dmitriy,

No, this is not an April's Foolk joke.

Previous discussions were largely centred around the implementations and bringing them together. With this thread my concern is the API and the churn our users would have to apply to their code base in order to use Qt 5 and Qt 6.

From: Dmitriy Purgin <dpurgin at gmail.com>
Sent: Thursday, April 23, 2020 9:53
To: Simon Hausmann <Simon.Hausmann at qt.io>
Cc: development at qt-project.org <development at qt-project.org>
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

Hi Simon,

I hope it's not a belated April's Fool joke? As far as I can remember, for the past few years, one would read everywhere to switch to QVector from QList because of this and that, and to choose QVector as the default choice container instead of QList like it was back in the days. I can't give the exact references but that's just the feeling I get from reading the docs and the Qt mailing lists.


On Thu, Apr 23, 2020 at 9:45 AM Simon Hausmann <Simon.Hausmann at qt.io<mailto:Simon.Hausmann at qt.io>> wrote:

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?

Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200423/502be5c9/attachment.html>

More information about the Development mailing list