[Development] QList

Ville Voutilainen ville.voutilainen at gmail.com
Mon Mar 20 19:11:47 CET 2017


On 20 March 2017 at 19:51, Marc Mutz <marc.mutz at kdab.com> wrote:
>> Perhaps we shouldn't get on that side track, but *I* didn't do it, I'm
>> not entirely convinced
>> it broke "an awful lot of lines of code", and it indeed specifically
>> did not and does not break very
>> vast swaths of existing code, because *every* function call still
>> behaves as they did before,
>> although certain pointer conversions don't. It certainly doesn't
>> produce a fear that
>> it would break "the whole world".
>
> I was just pulling your leg :)

That doesn't make the analogy more correct. :P

> Though it certainly broke a lot of Qt code and we're still recovering:
>
>   5a1b4832a2704e7fb386d6b4c73dab85facdc40b (QObject, QTimer)
>   c5e687895dd2eba3106f697b6e92b84683402403 (QtConcurrent; incomplete)

It can certainly break function wrappers.

>> > You can pay by porting to QVector. Or auto. That will work in Qt 5 and Qt
>> > 6. You can define your own MyQListOrQVector type alias. Or you can
>> > #ifdef. It's up to you.
>>
>> That's great, but before I have migrated all my code to any of those,
>> it's simply better
>> to change QList to be a QVector, fix the cases that require reference
>> stability (which you're
>> already doing in some places) to use a different type, deprecate
>> direct uses of QList
>> and *then* _eventually_ remove QList altogether, rather than doing it
>> without any grace
>> period.
>
> When I said "Kill QList in Qt 6", I mean eradicate it from our APIs. The name,
> too. Whether the QList class lives on to support legacy code is a different
> question. As long as it's deprecated, and maybe moved to a Qt5Support module
> (that name will have raised some hairs now :), I'm fine with that.


Right; I have been laboring under the misconception that you want to
completely remove the type,
not just remove it from APIs. However, I think it's still better to
keep the name in the APIs and change
the meaning of the name. That's far from ideal, but it still provides
a better compatibility story than
eradicating the name from APIs, and we can still take reasonable steps
towards eventually eradicating
the name.



More information about the Development mailing list