[Development] QList

[Ville Voutilainen]

On 18 March 2017 at 11:51, Marc Mutz <marc.mutz at kdab.com> wrote:
> On Saturday 18 March 2017 09:06:09 Ville Voutilainen wrote:
>> There's been a fair amount of talk about QList's future, so I'm curious:
>>
>> 1) What are the problems with QList?
>
> See Konstantin's reply. For me, the performance issue is pretty strong
> already, but that stability of references into QLists may depend on such
> subtleties as the machine's word size or whether Q_DECLARE_TYPEINFO has been
> called for the type is also a big correctness issue.

Ah, so there are correctness problems in addition to performance problems.

>> 2) What do we plan to do about those problems?
>
> Kill QList in Qt 6.

How much valid code will that break? How many bugs does that avoid?

> This experience, over several years, has thaught me that we need a technical
> solution. And so we started to specialize QList<QNewType> as an empty class.
> So far, this is the only workable solution I have found, and believe me, I am
> very determined.

As a technical point, reminding me of how std::hash is 'poisoned', and
why std::experimental::fundamentals_v2::nonesuch
exists, you might want to also prevent default construction, copy/move
construction and copy/move assignment.
Otherwise an innocent user might create an object of such a type, pass
it into a generic function and
get a fairly unwelcoming error deep in an instantiation chain.

> And since we now depend on enough C++11, replacing QList with QVector in
> generic code is trivial: either use auto, or when you can't, use
> QListOrVector, introduced here: https://codereview.qt-project.org/188858

Urgh. I can't say I'm a fan of functions that vary their return type
based on the characteristics of a template
parameter. Nor am I a big fan of "auto everywhere". But both might be
a necessary evil to provide a migration
path that avoids code breakage.

> So, here's my proposal for a QList exit strategy:
>
> In Qt 5:
>
> 1. Replace QList in generic code by QListOrVector, tell users to hold QLists
>    they get from Qt API only in type-deduced variables.

In other words, introduce generic code where there wasn't generic code
before - users writing
non-generic code calling non-templates that return QLists will need to
use deduction or a metaprogramming tool.

> 2. Fix any QList API missing (and not actively harmful) on QVector. E.g. I
>    don't think toSet() should be either on QList nor QVector, because it
>    creates nonsense like qHash(QItemSelectionRange) (please, please, look it
>    up :)
> 3. Disable QList for all new QFoo value types (by specializing QList<QFoo> as
>    an empty class).
> 4. Provide QArrayList for code that needs stability of references (stability
>    statically checked in Qt 5, enforced in Qt 6).

It seems that (4) is perfectly safe, whereas (2) and (3) are breaking
changes; to what extent, I would like to know.


> In Qt 6:
>
> 5. Replace all QList uses left with ... what ? QVector? std::vector?
>    -> separate discussion
> 6. Kill QList or keep it as a deprecated class.

This certainly seems feasible, but the migration and the extent of it
its interesting. There's a fair bunch
of QList-using code out there, afaik.