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