[Development] QList for Qt 6

[NIkolai Marchenko]

One change that is relatively painless but will set things for the later
reintroduction of QList as a proper class would be with Qt6 force rename
QList instances to Qt5SupportList.
Note that if it's done at the same time as removal of QList from Qt
interfaces entirely, then it's a simple pass of batch rename and then
replugging into Qt interfaces with actual correct classes.

The benefits of this are:
1) QList is officially deprecated and discouraged by its very name
2) Usercode that doesn't interface with Qt systems needs not be changed
outside the rename which can be fully automatic instead of on case by case
instance.
3) Come Qt7 QList can be reintroduced with an entirely different
implementation (because losing that name forever seems excessive)

On Fri, May 24, 2019 at 2:23 PM Konstantin Tokarev <annulen at yandex.ru>
wrote:

>
>
> 24.05.2019, 13:32, "Konstantin Tokarev" <annulen at yandex.ru>:
> > 24.05.2019, 13:06, "NIkolai Marchenko" <enmarantispam at gmail.com>:
> >>  All of the back and forth on this issue recently and over the years
> really make want to ask this question:
> >>
> >>  Is the promise of SC worth all the potenital pitfalls? There seems to
> be no end to the discussion with every solution requiriring hair rising
> compromises.
> >>  Is it _really_ that impossible to just remove QLIst entirely and force
> user to choose form a range of classes each tailored for the specific
> scenario that QList tried to cover?
> >>
> >>  As it is, it seems like we're rapidly heading to a nightmarish
> scenario worse than any SC breakage, where users will have to looks for
> problems in a perfectly compiling code.
> >>
> >>  Is the gordian knot of full SC really possible to unravel or is it
> time to axe it?
> >
> > If we remove QList, users with thousands of occurrences of QList in code
> base will likely do
> > mechanical replacement s/QList/QVector/g, or use the same template alias
> as it was proposed
> > earlier in this thread.
> >
> > To axe this problem, automatic clang-based porting tool is needed. Such
> tool would analyze
> > context and do a replacement of QList to QVector in places where it's
> least likely to introduce
> > issues, e.g. where QList is used with movable types which are not larger
> than void*, or where
> > QList is used as a local variable and it's possible to prove that
> references or iterators pointing
> > to this local QList members are never used after QList modification.
> >
> > If users end up with little manual work, it's more likely that they will
> carefully analyze all remaining
> > cases.
>
> Actually, clazy provides related checks "inefficient-qlist". I think
> following plan can work:
>
> 1. Implement opposite "replace-efficient-qlist-to-qvector" check in clazy
> which finds QList<T>
> where sizeof(T) <= sizeof(void*) and T is movable, and allows automatic
> replacement with QVector
>
> 2. Apply this transformation to all public and private Qt APIs, and
> refrain from QList replacements
> in places which are not sanctioned by tool.
>
> 3. Implement clazy check "inefficient-qvector-insert" which warns when
> prepend/push_front and
> insert into middle are used with QVector.
>
> Algorithm of porting to Qt 6 could be:
>
> 1. Run inefficient-qvector-insert over code base and store results
> 2. Apply replace-efficient-qlist-to-qvector to whole code base
> 3. Run inefficient-qvector-insert again and make a diff with step 1, and
> suggest user to check
> these cases carefully for possible reference issues and performance
> regressions
>
> Results:
> 1. Do a big chunk of worldwide QList elemination without compatibility
> hacks and with relatively
> low risk
> 2. Users should finally get the message that QList is not the go-to
> container preferred in most cases.
>
> Porting other part of QList usages can be delayed to Qt7.
>
> --
> Regards,
> Konstantin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190524/11bdfe38/attachment.html>