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@qt-project.org
https://lists.qt-project.org/listinfo/development

Reply via email to