[Development] Proposal: Deprecate QVector in Qt 6

[Matthew Woehlke]

On 20/05/2020 13.15, Lars Knoll wrote:
> On 20 May 2020, at 17:34, Matthew Woehlke wrote:
>> On 20/05/2020 09.11, Lars Knoll wrote:
>>> Here’s what we will do:
>>> * QList and QVector are aliases for each other
>>> * We make QList the main type, and QVector an alias to it
>>> * We keep both names, QList and QVector. None of them is deprecated
>> 
>> While I don't object to this as such, can someone remind me what is
>> the solution for people that *need* the semantics of old QList
>> (either reference stability or indirect allocation)?
> 
> There’s an option to provide a Q5List in qt5compat.

That's IMO a lousy option.

> Of course one could also add a new class to Qt 6 that always
> allocates indirectly.

This would be much better. I thought there had been talk of doing such?

> But in that case I would propose to redesign it, so that is uses
> block allocations to avoid at least some of the overhead of QList in
> Qt 5.

That sounds like std::colony, which has different trade-offs; in 
particular, it cannot be indexed (no random access). I don't necessarily 
object to such a container type (although if we do get std::colony, 
there is less of an argument for it), but if I have to choose one, I 
would prefer to keep Qt5 QList as it was, especially as that is much 
more feasible due to the additional work of adding a new type.

>> Also, will the new QVector/QList have the prepend optimization of
>> old QList?
> 
> Yes, see https://bugreports.qt.io/browse/QTBUG-84320

Cool, thanks for the info.

-- 
Matthew