[Development] QList

[Marc Mutz]

On Monday 20 March 2017 15:38:28 Ville Voutilainen wrote:
> On 20 March 2017 at 16:19, Marc Mutz <marc.mutz at kdab.com> wrote:
> >> And if I want to run the same code with Qt 5 and Qt 6? I don't want to
> >> modernize it,
> >> since that may change or break what it does on Qt 5, and I also don't
> >> want to modernize code
> >> as part of my build in a dynamic fashion, because that costs time and
> >> can cause version control problems. If we want Qt to be a library that
> >> caters to various different
> >> user scenarios, we should first stop assuming that one-way
> >> modernization tools are
> >> a realistic solution to compatibility problems.
> > 
> > That from someone that just broke an awful lot of lines of C++ code by
> > making noexcept be part of the function type :P
> 
> 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 :)

Though it certainly broke a lot of Qt code and we're still recovering:

  5a1b4832a2704e7fb386d6b4c73dab85facdc40b (QObject, QTimer)
  c5e687895dd2eba3106f697b6e92b84683402403 (QtConcurrent; incomplete)

it looks like every class that provides new-style connect syntax should be 
affected. Yes, we're to blame to not have centered this functionality in a 
qInvoke() template before, and maybe it's time to do that, but I certainly do 
not remember such a large SiC in C++ ever before. Well, in the last 17 years.

> > Well, seriously. My answer is the same: Time has only one direction. Qt
> > source and binary compatibility only has one direction. If you want to
> > use Qt in a way it was not intended to be used, then you need to pay the
> > prize, and not ask the community to do so for you.
> > 
> > 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.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts