[Development] QList for Qt 6

[Mutz, Marc]

Hi Lars,

On 2019-05-22 15:49, Lars Knoll wrote:
> Let’s conclude the topic of QList. I do see the concern about silent
> source breakages. Here’s what we’ll (I’ll) do then for Qt 6:
> 
> 1. Rename QList to QArrayList and make QList an alias to QArrayList

Agreed.

> 2. Move QStringList and QByteArrayList over to inherit from QVector
> (that should be source compatible)

Agreed.

> 3. Rename QStringList to QStringVector (keep QStringList as a
> compatibility name), same for QBAList

Not necessary, in my mind (List is a general concept, think ListView, 
not just a linked list). But not strongly opposed b/c/o the compat 
typedef.

> 4. Use QVector to implement QList<Foo>, if sizeof(Foo) <=
> sizeof(quint64) and Foo is movable. I’m intentionally not using
> sizeof(void *) here, as types with sizes between 4 and 8 bytes would
> not have stable references in cross platform code, so I do not believe
> lots of code would assume that (or it would have broken on 64 bit).

Agreed. This matches what QList currently does, minus the padding, which 
is good.

> 5. Add a compile time switch that allows mapping QList completely to
> QVector or to a compatibility mode where QLists of large/non movable
> types are mapped to QArrayList

I agree with the compile-time switch, provided a) it defaults to QList 
as per (4), otherwise QArrayList (iow: Q5List behaviour minus the 
padding) and b) the switch goes away before Qt 6.0.0 is released. I see 
this as a way to help wip/qt6 get to all-vector APIs without breaking 
the world. So CI on wip/qt6 would flip the switch to all-vector to see 
what breaks, at the same time the default would be to keep 
Q5List-mod-padding to not destroy git-bisect-ability across wip/qt6 
commits.

> 6. For now we don’t yet want to explicitly change all our API that
> uses QList to use QVector (as that would make merging from dev a pain,
> let’s do that later this year). But to test that everything we have
> works with QVector, we’ll set the compile switch to default to mapping
> to QVector.

This is the only reason why I'd accept a compile switch, and that's why 
I'd very much like it to be gone by Qt 6, and why I think it shouldn't 
default to QVector. The CI can test with that (and with the old 
behaviour), individual developers may choose what they want, too, but 
the default for the wider audience tracking development should be 
backwards-compat. We don't want Qt to break for everyone because a few 
people are trying to eradicate the last reference-stability users.

> 7. Make the implementation of QArrayList fully inline and deprecate the 
> class.

I don't think it needs to be fully inline, but I'm not opposed. If it's 
called QArrayList and always heap-allocates, incl. for <int>, I'm also 
not sure it needs deprecating.

> Let me know if there are any major concerns with this plan. It should
> give us a good compromise, where we can move all of Qt over to QVector
> and test things early, as well as providing a compatibility mode for
> our users (slower but won’t silently break).

To summarize: I agree with the plan, provided QList in Qt 6.0.0 
unconditionally behaves like Q5List-mod-padding (upping the trigger from 
sizeof(void*) to 8 is ok, too), QList as as name is deprecated and as 
any type has implicit deprecated conversions from/to QVector.

Thanks,
Marc