[Development] QList for Qt 6

[Lars Knoll]

Hi,

Been trying to implement this, and of course there are some complications :)

> On 22 May 2019, at 21:36, Mutz, Marc via Development <development at qt-project.org> wrote:
> 
> 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.

I tried this, and the problem here is that this requires T to be fully declared at the time you instantiate QList<T>. This is a source incompatibility for class declarations such as

class MyClass {
	QList<MyForwardDeclaredType> list;
};

This worked in Qt 5, but wouldn’t work here anymore as I can’t select the implementation of QList for a forward declared class.

At the same time, I’m not really willing to compromise on this point, as I really want to have a zero copy conversion between QList and QVector for small movable types (the most common case).

> 
>> 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.

I don’t see why you’d want to remove the switch for Qt 6. It would be a porting help for application developers.
> 
>> 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’s see. I agree that we should in this case consider it always using IndirectLayout to make it consistent and easy to understand.

Cheers,
Lars

> 
>> 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
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development