[Development] QList for Qt 6

Mutz, Marc marc at kdab.com
Thu May 16 15:05:37 CEST 2019


Hi Lars,

On 2018-11-02 08:51, Lars Knoll wrote:
> I believe I have a solution to get rid of QList without breaking SC in
> any major way. See https://codereview.qt-project.org/#/c/242199/ and
> the following changes.
[...]
> So to re-iterate: We will not break SC in major ways. The goal is to
> make porting from Qt 5.x to 6 as easy as possible.

It's technically SC alright, but silently breaking the reference 
stability user code may rely on should be a complete no-no, considering 
how reluctant Qt has been since the Qt 3->4 port with disruptive 
changes. I welcome the openness to rethink the necessity of some of the 
plumbing infrastructure, but it appears that you have come out far on 
the other side on this one.

As I said a few years ago, QList in Qt 5 should have a warning if it 
keeps reference stability (iow: if it's not already behaviour- if not 
structure-compatible with QVector), indicting very strongly that by Qt 
6, this use-case will be gone. Then port all of Qt's own code away from 
QList, either to QVector, or, say, std::vector<std::unique_ptr>, like in 
QToolBox (https://codereview.qt-project.org/261943), which is a case 
where a user that actually relies on the implicit reference-stability 
guarantee of current QList, then deprecate QList.

Back then I suggested to rename QList to QArrayList and have QList be a 
deprecated template alias for _either_ QArrayList or QVector, depending 
on whether Q5List would keep references stable or not.

Please don't make QList an unconditional alias for QVector. You are 
silently breaking Qt code (cf. QToolBox) along with an unknown amount of 
Qt-user's code. Make the break non-silent.

I understand the desire to keep old code working that was written 
against Qt 5. But to me, the better solution would be to have the Qt 6 
API explicitly return QVector and have implicit, but deprecated, 
conversions between QList and QVector. The priority should be to not 
break code. It should not be a priority to have unported code enjoy 
optimal speed. An actual copy on implicit QVector -> QList conversion is 
acceptable, IMO, since the solution for codebases targeting both Qt 5 
and 6 is simple: use an auto variable.

Going forward, we should be looking into removing more and more owning 
containers from the interface and replace them with views. The standard 
is working on a solution for the stale reference problem, and by the 
time Qt 7 comes around, it will be hopefully widely available.

Thanks for considering,
Marc



More information about the Development mailing list