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