[Development] Proposal: Deprecate QVector in Qt 6

[Vitaly Fanaskov]

I think we should completely remove QList in Qt6. It was planned before, as far as I remember. The main reason is to be consistent with STL wording and do not violate POLA too much.

I read the entire discussion, and I'd like to say this one more time: we don't have to fight the consequences. Better to eliminate a cause. There always will be a functionality to deprecate. There always will be controversial APIs, that, for example, contain a hard-coded type information in the name (e.g. "windowList()" instead of "windows()"). Why not think about it instead? Today it QVector vs. QList, tomorrow something else...

We can at least shorten release cycle to one year.
Provide clang-based tools to (semi-)automatically port users' code bases to a new version of Qt. These tools might either fix a code or at least add a comment in potentially problematic places where a user should correct the code. A developer who changes API should also implement a rule for these tools.
And of course slightly adjust API design guides.


Vitaly

________________________________
From: Development <development-bounces at qt-project.org> on behalf of Simon Hausmann <Simon.Hausmann at qt.io>
Sent: Thursday, April 23, 2020 09:43
To: development at qt-project.org <development at qt-project.org>
Subject: [Development] Proposal: Deprecate QVector in Qt 6

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?


Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200423/403edbb5/attachment.html>