[Development] QList for Qt 6

[NIkolai Marchenko]

For the record: I would also prefer QList to vanish from Qt's interfaces
rather than change its meaning everywhere it's used.
Better have explicit porting than subtle hard to track bugs.

On Mon, May 20, 2019 at 3:41 PM Mutz, Marc via Development <
development at qt-project.org> wrote:

> Hi Lars,
>
> I'm on record for claiming QList needs to die, and I work for a company
> that still makes part of its living by porting Qt 3 apps to Qt 4 (and
> 5). So I should be celebrating if you create more potential work for
> KDAB, but I'm actually ok with keeping QList.
>
> Provided it vanishes from each and every Qt API.
>
> Whether to call it Q5List or QArrayList or continue with QList doesn't
> matter. Actually, I'd err on keeping QList, to minimize porting. What I
> want to avoid is to break user code silently. Asan is a runtime-checker,
> the code must actually be exercised, which is trivial for QToolBox but
> might be problematic if it's in, say, error handling code. And you
> rightfully pointed out that it's very hard for a static checker to find
> cases where reference stability is used. Not impossible, but hard.
>
> I want to understand what problems you see with keeping QList as-is with
> deprecated implicit conversions to and from QVector, assuming all Qt API
> that uses QList is ported to QVector.
>
> The way I see it:
>
> Given:
> * QList stays as-is
> * No Qt API takes or returns QList anymore, but QVector
> * QList implicitly converts to QVector, and vice versa
> * These implicit conversions are marked as deprecated
>
> Pros:
> * Old (user) code doesn't silently change the meaning
> * Old (user) code continues to work, lets users port at their own
> leisure
> * Receiving objects can be done with auto variables for optimal
> performance
>    or with QList for old code.
> * Users passing QLists into Qt APIs enjoy the implicit conversion to
> QVector
>    + This might be slow, but you say yourself that speed doesn't matter
>      for 95% of the code and it's easier to find and fix slow code in
>      the 5% than it is to find a silent reference stability breakage in
>      the 95%.
>
> Cons:
> * Unported code will get penalized by the implicit conversions from and
> to QList
>    + But using the 95/5-argument here, again: it's easier to find where
> the app
>      got slower in the 5% than to find a bug in the 95%.
>
> The pros far, far outweigh the cons. I'd very much like to know in which
> aspects inheriting QList from QVector fares better than this proposal.
>
> My fear is that QList : QVector will lead to some of Qt's APIs
> continuing to use QList, which would lock Qt into QList for another
> major release cycle and only postpone the inevitable QList removal.
> C++11 gave us the tools to make this transition now much smoother than
> it could have been done in Qt 4->5. Inheriting QList from QVector is
> both technically wrong (value classes inheriting each other) and just
> serves to confuse users (is it still ok to use QList? Is it now suddenly
> ok after it wasn't in Qt 5? What do to if I target both Qt 5 and Qt 6?).
>
> Touché on the QStringView reference :)
>
> Thanks,
> Marc
> _______________________________________________
> 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/20190520/c96b1935/attachment.html>