[Development] QList

[Marc Mutz]

On Saturday 18 March 2017 10:51:06 Marc Mutz wrote:
> 4. Provide QArrayList for code that needs stability of references
> (stability statically checked in Qt 5, enforced in Qt 6).

There's disagreement over this last part. I have opted to provide a 
constrained type alias QArrayList that can only be used to alias QLists that 
already use QListData::IndirectLayout (= pointers to heap-allocated objects).

The intent was to allow QArrayList use in existing API. E.g., and I'm not sure 
I'm proposing this, QList<QVariant> could be renamed to QArrayList<QVariant> 
because it currently is. And some users may have come to depend on the 
stability-of-references feature provided by inefficient QLists.

A type alias makes this trivial, because it introduces neither SC nor BC. It's 
simply a way to document, and statically check, that that particular QList has 
IndirectLayout.

The other option would be to copy QList, strip out the optimisation that makes 
it use layouts other than IndirectLayout and call the result QArrayList.

Disadvantages:

- migration of QLists used in APIs has to wait until Qt 6
- two almost identical code bases that are very likely to get out of sync,
  accidentally or intentionally, before one of them gets ditched in Qt 6
- duplicate documentation to write, maintain, explain difference, ...
  With the type alias, we just need to document the alias.

So, updated and refined tail of QList exit strategy would be:

4. Provide a type alias, QArrayList, for QList, constrained on actually
   QListData::IndirectLayout QLists. Use it to mark QList uses that either
   a. are (includes QVariant, QModelIndex, QImage, QPixmap, ...)
   b. should conceptually be (excludes QVariant, QModelIndex, ...)
   array lists (ie. arrays of pointers to heap-allocated objects) in a BC and
   SC way.

In Qt 6: (the -5- and -6- just refer to the Qt 5 and Qt 6 versions of the 
names):

5. Q5List -> Q6ArrayList, strip out non-IndirectLayout code, making it always
   use IndirectLayout.
6. Provide a deprecated type alias Q6List that resolves to either Q6Vector or
   Q6ArrayList, depending on similar conditions Q5List used before.
7. Replace all Q6List uses in API with either Q6ArrayList or Q6Vector. 

Advantages:

- only one QList implementation to maintain and document in both Qt 5 and 6.
- adjustable SC:

Because this introduces a SiC/SC knob that's interesting to turn:

If Q6List uses the exact same conditions as Q5List, Q6List<UserType> would 
have the same layout as Q5List<UserType>, making 'QList<UserType>' SC. But 
Q6List<QVariant> would map to Q6ArrayList<QVariant> while the Qt API very 
probably will have migrated to Q6Vector<QVariant>, making 'QList<QVariant>' 
SiC.

If we, say, dropped the isLarge trait from the condition, then some 
Q6List<UserType> would switch memory layout, breaking stability of references 
for some UserTypes, compared to Q5List, making 'QList<UserType>' SiC. But 
Q6List<QVariant> would map to Q6Vector<QVariant>, making 'QList<QVariant>', 
QList<QString> etc. SC.

Not sure where that knob will end up, but it's nice that it's there.

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