<div dir="ltr">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.<div>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.</div><div><br></div><div>The benefits of this are:</div><div>1) QList is officially deprecated and discouraged by its very name</div><div>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.</div><div>3) Come Qt7 QList can be reintroduced with an entirely different implementation (because losing that name forever seems excessive)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 24, 2019 at 2:23 PM Konstantin Tokarev <<a href="mailto:annulen@yandex.ru">annulen@yandex.ru</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
24.05.2019, 13:32, "Konstantin Tokarev" <<a href="mailto:annulen@yandex.ru" target="_blank">annulen@yandex.ru</a>>:<br>
> 24.05.2019, 13:06, "NIkolai Marchenko" <<a href="mailto:enmarantispam@gmail.com" target="_blank">enmarantispam@gmail.com</a>>:<br>
>>  All of the back and forth on this issue recently and over the years really make want to ask this question:<br>
>><br>
>>  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.<br>
>>  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?<br>
>><br>
>>  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.<br>
>><br>
>>  Is the gordian knot of full SC really possible to unravel or is it time to axe it?<br>
><br>
> If we remove QList, users with thousands of occurrences of QList in code base will likely do<br>
> mechanical replacement s/QList/QVector/g, or use the same template alias as it was proposed<br>
> earlier in this thread.<br>
><br>
> To axe this problem, automatic clang-based porting tool is needed. Such tool would analyze<br>
> context and do a replacement of QList to QVector in places where it's least likely to introduce<br>
> issues, e.g. where QList is used with movable types which are not larger than void*, or where<br>
> QList is used as a local variable and it's possible to prove that references or iterators pointing<br>
> to this local QList members are never used after QList modification.<br>
><br>
> If users end up with little manual work, it's more likely that they will carefully analyze all remaining<br>
> cases.<br>
<br>
Actually, clazy provides related checks "inefficient-qlist". I think following plan can work:<br>
<br>
1. Implement opposite "replace-efficient-qlist-to-qvector" check in clazy which finds QList<T><br>
where sizeof(T) <= sizeof(void*) and T is movable, and allows automatic replacement with QVector<br>
<br>
2. Apply this transformation to all public and private Qt APIs, and refrain from QList replacements<br>
in places which are not sanctioned by tool. <br>
<br>
3. Implement clazy check "inefficient-qvector-insert" which warns when prepend/push_front and<br>
insert into middle are used with QVector.<br>
<br>
Algorithm of porting to Qt 6 could be:<br>
<br>
1. Run inefficient-qvector-insert over code base and store results<br>
2. Apply replace-efficient-qlist-to-qvector to whole code base<br>
3. Run inefficient-qvector-insert again and make a diff with step 1, and suggest user to check<br>
these cases carefully for possible reference issues and performance regressions<br>
<br>
Results:<br>
1. Do a big chunk of worldwide QList elemination without compatibility hacks and with relatively<br>
low risk<br>
2. Users should finally get the message that QList is not the go-to container preferred in most cases.<br>
<br>
Porting other part of QList usages can be delayed to Qt7.<br>
<br>
-- <br>
Regards,<br>
Konstantin<br>
<br>
</blockquote></div>