[Development] QList for Qt 6

[NIkolai Marchenko]

>   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.fanaskov at 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 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.
>
> 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 at qt-project.org
> https://lists.qt-project.org/listinfo/development
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190516/b39f7ff4/attachment.html>