[Development] QList

[Marc Mutz]

On Wednesday 29 March 2017 13:39:34 Ville Voutilainen wrote:
> > Bottomline: don't expect me to support any form of implicit sharing. The
> > answer will always be: because you should use explicit sharing.
> > 
> > This is why I see QArrayList as a phase-out vehicle for QList, not as a
> > fancy new container.
> 
> All this makes me wonder why we should have QArrayList at all. If it's
> slated for immediate deprecation,

I said _I_ would immediately deprecate it. Wether we do depends on a lot of 
other things, too. E.g. what will happen to our other containers.

> we perhaps should never let it out, and just tell people to use
> QVector or QLinkedList instead of QList.

It's part of the QList exit strategy. Q6ArrayList will be one and Q6Vector the 
other implementation underlying Q6List, which then will be the template alias 
that contains the std::conditional that we currently have inside QList.

We can't make QLinkedList the other implementation beside QVector, since 
QLinkedList does not provide an efficient index-based API (even though Qt 
tried that, too: http://doc.qt.io/qt-4.8/q3valuelist.html). Like the 
Q3ValueList in that link, it's a vehicle to keep old source working.

Unlike Q4List, I propose to add Q5ArrayList as an alias to Q5List so users can 
start pointing out in their code pleases where they require the list-ness of 
QList, before Qt 6 comes along. Likewise, Qt can provide in its API hints 
which QLists provide stable references and which don't. Which of those we port 
to QVector (probably all) and which ones we keep as QArrayList (probably 
none), come Qt 6, is an entirely different matter.

By making QArrayList an alias in Qt 5 and QList an alias in Qt 6, we keep 
these types out of the ABI while maintaining SC and BC.

That is, IMO, why we need QArrayList.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts