[Development] QList

[Marc Mutz]

To bring this thread back on-topic:

I have prepared a patch that implements QArrayList as outlined below (as a 
template alias): https://codereview.qt-project.org/188938

The only well-known user of stable references into QList, QToolBox, is 
"ported" here: https://codereview.qt-project.org/188941

Please approve the former, or propose something else.

If we go with QArrayList, the next question is whether we use it in code that 
has been proven to require stability of references (only possible when you 
know the code!) or wherever QList<T> _currently_ provides stable references on 
all platforms (QList<double>: no; QList<QModelIndex>: yes). The latter might 
be necessary to support code we don't know, ie. user code, ie. in our APIs.

I actually don't really intend to merge the latter, because Kevin said he'd 
look into porting that one away from QList (note: I didn't say "promised"), 
and I still have hope.

Thanks,
Marc

On Monday 20 March 2017 23:02:22 Marc Mutz wrote:
> 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