[Development] QList for Qt 6

[Lars Knoll]

On 23 May 2019, at 10:40, Lars Knoll <lars.knoll at qt.io<mailto:lars.knoll at qt.io>> wrote:

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<mailto: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).

See https://codereview.qt-project.org/c/qt/qtbase/+/262602 for a WIP change implementing this.



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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190523/a49473bf/attachment.html>