[Development] QList

[André Pönitz]

On Sat, Mar 18, 2017 at 10:06:09AM +0200, 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?

The main problem is that the idea of what Qt is meant to be has changed
over time, or, at the very least, is being attempted to be changed by some.

Qt was prioritizing application developer convenience over raw performance,
making it easier for an application developers to create something working
in reasonable time. That included features like consistency in the API
and naming in general that made it possible to transfer knowledge of one
part of the API to another. This also included recommendations for "one
size fits all" usage patterns including default choices for containers.

Of course there is no single container that is best for all uses, and never
will be. QList is a compromise to provide something with acceptable worst
-case behaviour under a "one type needs to fit all" constraint.

It is pretty much *never* the best container for any specific task, so
it's easy to make QList look bad in 1:1 comparisons in restricted setups
but it serves its purpose of not producings pathological results in 
common cases like appending, prepending, insertion in the middle.

> 2) What do we plan to do about those problems?

I am afraid "we" needs qualification on this list. It can mean people
reading the list, the project, the company, indviduals with a streak
of using the pluralis majestatis in normal speech, and more.

If it's about decision making: I don't see consensus here, so my expectation
would be either "not much", or "whatever the Chief Maintainer decides".

> 3) How do we expect to migrate code that uses it?

I personally would not like to see much user code migration being necessary.
Qt 3 to Qt 4 was a pain, effectively meaning rewrite of large parts of Qt
applications. With that lesson learned, Qt 4 to Qt 5 was mostly source
compatible, and as far as I am concerned this worked rather well.

Aliasing QList to QVector might be a feasible option, or maybe replacing
QList implementation by QVector's, and replacing QVector by something
not reference-counted.

Andre'