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.
This is good direction. But I would suggest something based on ranges (accepted for C++ 20 and there is already ranges-v3 on github or ranges in boost). What we should return in our API is lazy range object. This is actually a sort of view or chain of nested views with some conditions. If a user needs a regular container, range might be simply assigned to it. -- Best Regards, Fanaskov Vitaly Senior Software Engineer The Qt Company / Qt Quick and Widgets Team On 16 May 2019, at 15:05, Mutz, Marc via Development <development@qt-project.org<mailto:development@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. 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 _______________________________________________ Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> https://lists.qt-project.org/listinfo/development
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
