[Development] QList

Ville Voutilainen ville.voutilainen at gmail.com
Sat Mar 18 20:05:59 CET 2017


On 18 March 2017 at 19:37, Marc Mutz <marc.mutz at kdab.com> wrote:
>> In other words, introduce generic code where there wasn't generic code
>> before - users writing
>> non-generic code calling non-templates that return QLists will need to
>> use deduction or a metaprogramming tool.
>
> No, that is false. You can keep using QList for now everywhere you used it so
> far, in non-generic code. Nothing changes for existing types. And for new
> types, the compiler will make sure that you don't get away with QList. We do
> recommened to use auto to receive QLists to avoid having to port these code
> lines manually come Qt 6. I do not consider auto variables "generic code".

Right. I, however, do consider them generic code. :) I don't use them when they
introduce a possibility that the type I *want* changes to another
type. That might
well *not* be a case for a QList->somethingelse transition.

>> > 3. Disable QList for all new QFoo value types (by specializing
>> > QList<QFoo> as
>> >
>> >    an empty class).
>> >
>> > 4. Provide QArrayList for code that needs stability of references
>> > (stability
>> >
>> >    statically checked in Qt 5, enforced in Qt 6).
>>
>> It seems that (4) is perfectly safe, whereas (2) and (3) are breaking
>> changes; to what extent, I would like to know.
>
> (2) is possibly breaking, yes. We should intercept by deprecating
> QList::toSet() and re-adding it as a free function.
>
> (3) is breaking nothing for existing code, since it only applies to new types.
> New types don't magically show up in your source code. You have to introduce
> them yourself. As for existing generic code, it's a source-incompatibility
> that is accepted, because it can be fixed by using auto variables. Or you

Fair enough, but since it's a source-incompatibility, it *is* a breaking change.
What, if anything, it really breaks is the important question.


>> > In Qt 6:
>> >
>> > 5. Replace all QList uses left with ... what ? QVector? std::vector?
>> >
>> >    -> separate discussion
>> >
>> > 6. Kill QList or keep it as a deprecated class.
>>
>> This certainly seems feasible, but the migration and the extent of it
>> its interesting. There's a fair bunch
>> of QList-using code out there, afaik.
>
> Indeed, if it was easy, it would have been done long ago. But it's nonetheless
> absolutely necessary. Q6String will not fit into a QList anymore. QVariant and
> QModelIndex already don't. And given the extensive use of QVariant in QML/Qt's
> property system, I don't think anyone can be happy about the per-element
> memory allocation in QVariantList.


Ok. I think the first thing we need is the QList replacement, whatever
it is. I think the poisoning
ideas can follow that, if at all.



More information about the Development mailing list