[Development] QList for Qt 6

[Konstantin Tokarev]

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.

If we are not ready to provide such tool before 6.0 release, IMO it would be better to avoid touching
QList at all, and instead concentrate on removing QList from public APIs. In this case users can
start porting their code from places where conversions between QList and QVector introduce visible
impact on performance, and start writing new code with QVector.


-- 
Regards,
Konstantin