[Development] QList for Qt 6

[Lars Knoll]

Hi Marc,

> On 16 May 2019, at 15:05, Mutz, Marc via Development <development at qt-project.org> wrote:
> 
> 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.

I don’t think so. At least not if we provide a fully compatible QList in e.g. a Qt5Support module/namespace, and allowing the app to use it with a simple switch.
> 
> 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.

This is our job now for 5.14/5.15. Make sure we add warnings for all use cases we don’t want to support in Qt 6 anymore. The problem with stability of those references is that it’s unfortunately rather hard to have them detected by the compiler.

Having said that, this is the only major source breakage, and it’s a relatively uncommon one. In addition, a build with address sanitiser enabled should quickly find those, so I don’t think it’s something we need to keep by default until everybody manually changed all their code to use QVector.

> 
> 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.

That would be more source compatible. But I would really not want to continue to return and take QLists in our public APIs. And if we don’t do that Qt6 will basically incur a copy between (un-ported) user code and Qt code. The question is whether not having that overhead is more important than reference stability 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.

Auto doesn’t always work. It works for return values, but it won’t work for objects the user creates and wants to pass into Qt API.

Another option (outlined above) could be a compile switch between your idea (fully SC, but performance penalty) and mine (slightly SIC, but no performance penalty). Users could then choose which way they want to go.
> 
> 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.

Let’s keep that discussion separate. But if we’re going on that tangent, we should at least finish the QStringView related work for Qt 6.

Cheers,
Lars