[Development] QList for Qt 6

[Mutz, Marc]

Hi Lars,

I'm on record for claiming QList needs to die, and I work for a company 
that still makes part of its living by porting Qt 3 apps to Qt 4 (and 
5). So I should be celebrating if you create more potential work for 
KDAB, but I'm actually ok with keeping QList.

Provided it vanishes from each and every Qt API.

Whether to call it Q5List or QArrayList or continue with QList doesn't 
matter. Actually, I'd err on keeping QList, to minimize porting. What I 
want to avoid is to break user code silently. Asan is a runtime-checker, 
the code must actually be exercised, which is trivial for QToolBox but 
might be problematic if it's in, say, error handling code. And you 
rightfully pointed out that it's very hard for a static checker to find 
cases where reference stability is used. Not impossible, but hard.

I want to understand what problems you see with keeping QList as-is with 
deprecated implicit conversions to and from QVector, assuming all Qt API 
that uses QList is ported to QVector.

The way I see it:

Given:
* QList stays as-is
* No Qt API takes or returns QList anymore, but QVector
* QList implicitly converts to QVector, and vice versa
* These implicit conversions are marked as deprecated

Pros:
* Old (user) code doesn't silently change the meaning
* Old (user) code continues to work, lets users port at their own 
leisure
* Receiving objects can be done with auto variables for optimal 
performance
   or with QList for old code.
* Users passing QLists into Qt APIs enjoy the implicit conversion to 
QVector
   + This might be slow, but you say yourself that speed doesn't matter
     for 95% of the code and it's easier to find and fix slow code in
     the 5% than it is to find a silent reference stability breakage in
     the 95%.

Cons:
* Unported code will get penalized by the implicit conversions from and 
to QList
   + But using the 95/5-argument here, again: it's easier to find where 
the app
     got slower in the 5% than to find a bug in the 95%.

The pros far, far outweigh the cons. I'd very much like to know in which 
aspects inheriting QList from QVector fares better than this proposal.

My fear is that QList : QVector will lead to some of Qt's APIs 
continuing to use QList, which would lock Qt into QList for another 
major release cycle and only postpone the inevitable QList removal. 
C++11 gave us the tools to make this transition now much smoother than 
it could have been done in Qt 4->5. Inheriting QList from QVector is 
both technically wrong (value classes inheriting each other) and just 
serves to confuse users (is it still ok to use QList? Is it now suddenly 
ok after it wasn't in Qt 5? What do to if I target both Qt 5 and Qt 6?).

Touché on the QStringView reference :)

Thanks,
Marc