> If a user needs a regular container, range might be simply assigned to it. It depends on what you expect the average usecase to be. If we assume that a regular container is generally more used then you are preventing ppl from "almost always auto"
On Thu, May 16, 2019 at 9:35 PM Vitaly Fanaskov <vitaly.fanas...@qt.io> wrote: > 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> 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 > https://lists.qt-project.org/listinfo/development > > > _______________________________________________ > Development mailing list > 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
