[Development] QList for Qt 6
marc at kdab.com
Mon May 20 14:39:42 CEST 2019
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:
* 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
* Old (user) code doesn't silently change the meaning
* Old (user) code continues to work, lets users port at their own
* Receiving objects can be done with auto variables for optimal
or with QList for old code.
* Users passing QLists into Qt APIs enjoy the implicit conversion to
+ 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
* Unported code will get penalized by the implicit conversions from and
+ But using the 95/5-argument here, again: it's easier to find where
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 :)
More information about the Development