[Development] Proposal: Deprecate QVector in Qt 6

NIkolai Marchenko enmarantispam at gmail.com
Fri Apr 24 18:53:43 CEST 2020


>  But if the majority thinks that the class name is burned
Majority of whom? I am fairly certain most Qt developers either didn't know
about QList controversy or didn't care about it enough to consider it in
their code.
The only people who care are ones in this mailing list most likely. Imo.

On Fri, Apr 24, 2020 at 7:36 PM Joerg Bornemann <joerg.bornemann at qt.io>
wrote:

> On 4/24/20 18:10, Giuseppe D'Angelo via Development wrote:
> > On 4/24/20 8:57 AM, Joerg Bornemann wrote:
> >>
> >> Alternatively, proposal 3 (aka "do almost nothing"):
> >>       template <typename T> class QVector { implementation }
> >>       template <typename T> using QList = QVector<T>;
> >>
> >> No deprecation of QVector.
> >> No replacement of QList with QVector in our API.
> >>
> >> Rationale: QList is our default sequential container, and in Qt6 we just
> >> change its implementation.
> >
> > Could you please argument a bit more? In particular:
> >
> > * Is it OK to live with a mixup of containers in the APIs? What's the
> > downside in terms of consistency, teachability, learning, etc.?
>
> No, IMO it's not OK to have a mix of QVector/QList in our public APIs.
> Most of the time the user is interested in the fact that they have to
> pass or get sequence of items. Be it QVector, QList or something else.
>
> We should settle on one type and use it consistently.
> Historically, QList was this general purpose container.
>
> > * If I'm adding a new function, what would the coding guideline be,
> > take/return QList or QVector? Why?
>
> Use the agreed-on general purpose container of Qt. If you use another
> container, have a good reason.
> Why? Consistency.
>
> > * What's the reason against the replacement? It's not worth it in terms
> > of manpower, or another guideline?
>
> I'm not strongly against the replacement. I'm strongly against the
> deprecation. If QList==QVector I really don't care about the
> replacement. But I, personally, wouldn't invest in changing every
> occurrence of QList to QVector. I really don't see the benefit.
>
> IMHO, we can keep using QList. The only thing we have to do is to
> communicate the fact that QList's implementation has been fixed/adjusted
> to current requirements for Qt6. But if the majority thinks that the
> class name is burned, so be it. Use QVector in the API and replace like
> there's no tomorrow. But don't deprecate QList or QVector as this will
> be a heavy burden for projects migrating from Qt5 to 6 or projects that
> - God forbid - support both versions.
>
>
> Stay healthy,
>
> Joerg
> _______________________________________________
> 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/20200424/7fe99549/attachment.html>


More information about the Development mailing list