[Development] QList for Qt 6

[Lars Knoll]

> On 23 May 2019, at 13:26, Mutz, Marc via Development <development at qt-project.org> wrote:
> 
> On 2019-05-23 10:40, Lars Knoll wrote:
> [...]
>>>> 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.
> 
> I agree we should not break this. The standard has just added similar guarantees for it's own containers.
> 
>> 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).
> 
> I don't see why a zero-copy conversion between QList and QVector for vector-like QList is needed.

Because I don’t want to have larger performance regressions in our users code if we can avoid it.
> 
> You said that QList should vanish from Qt API. So we don't care. We'll have that switch to make QList _be_ QVector for ese of porting, but as a template alias. There's your zero-copy conversion :) That leaves users. And I repeat: I'd leave QList alone (as QArrayList, possibly with always IndirectLayout), and just have implicit deprecated conversions between QArrayList and QVector. You shouldn't care about performance of unported code: It's easy to target both Qt 5 and Qt 6 if you use auto for receiving from Qt API. For sending to Qt API, it's a bit more tricky. You need to ifdef or live with the implicit conversion in a Qt 6 build, but it's not something that we should optimize for. Really. Don’t.

Sorry, but no. Larger performance regressions that are not really visible/cought at compile time can be as large a headache to our users as the non stable references to data in the container.

I’d argue that it might cause the larger amount of problems as keeping references to data in the container is something that’s not used very often. But *everybody* will have tons of conversions between QList and QVector with your plan for unported code. IMO that’s just as bad.

Cheers,
Lars

> 
> So, I'd try the following:
> 
> - have a compile switch that hides QList and replaces it with a template alias to QVector. This is BC if you compiled with the switch off. Clients using the alias will never see the QList name, so won't use the code compiled into QtCore for it. So, no need to make it all-inline.
> 
>    #if QList-as-QVector
>    template <typename T> using QList = QVector<T>;
>    #else
>    ~~~ QList impl, unchanged, except for implicit deprecated conversions to/from QVector added ~~~
>    #endif
> 
> - port QtCore away from QList
> 
> - flip the switch (in CI) for all other libraries except QtCore (so QtCore keeps compiling QList in, for other users)
> 
> - deal with the fallout
> 
> - once reasonably sure all stability-of-reference users have been ported away from QList, do s/QList/QVector/g when convenient and unflip the switch in CI
> 
> - ok, so keep the switch for final release, buf off (and it never affects the QtCore build)
> 
> - bonus: rename QList to QArrayList, using IndirectLayout unconditionally, and make the name 'QList' a deprecated template alias for (depending on compile switch) QArrayList (default) or QVector (for the fireworks). I'd go to this length _only_ if we think that QArrayList (always IndirectLayout) is a worthwhile container to have (remember, there's always vector<unique_ptr>) and thus it's going to be maintained going forward. If it's not, I'd leave it as QList and deprecate it.
> 
> Thanks,
> Marc
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development