[Development] QList for Qt 6

[Konstantin Tokarev]

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