[Development] Proposal: Deprecate QVector in Qt 6

[Joerg Bornemann]

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