[Development] Proposal: Deprecate QVector in Qt 6

[Morten Sørvig]

> On 23 Apr 2020, at 11:30, Ville Voutilainen <ville.voutilainen at gmail.com> wrote:
> 
> On Thu, 23 Apr 2020 at 12:25, Philippe <philwave at gmail.com> wrote:
>> 
>> Almost all the time I second your positions, but not this time ;)
>> 
>> QList is historically a cause of ambiguity, and Qt6 is the chance to get rid of that.
> 
> Indeed. QList causes confusion for the uninitiated that are aware of
> the differences between std::vector and std::list
> (as in Why Do These People Use Lists Everywhere? Why don't they use
> Vectors?). Now we have papered over
> the problem, but the name remains problematic, because QList is not a
> list. In Qt5, QList is sometimes a list,
> sometimes a vector, but in Qt6 it's never a list.

Well at this point and on todays hardware the linked list has become a
very special-purpose container, so it might be reasonable to disambiguate
the other way: “list” is a sequential container but no longer implies “linked”.
It’s not a perfect naming, but we can get away with it :)

QList is our chameleon sequential container whose implementation we can change
to meet new requirements (to a certain degree), now and in the future.

> 
> Switching the QVector implementation over to a type called QList and
> aliasing QVector to that with the intent
> of getting rid of the QVector name seems exactly backwards to me. I
> would think the better approach would
> be to keep dev as it is, and deprecate and eventually remove QList.

QVector, on the other hand, guarantees contiguous storage and also has a place,
like for graphics API as pointed out elsewhere in this thread.

(We should then be careful about adding QList::constData() as public API, since
that will tie down the QList implementation).

- Morten
 


> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development