[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