On Monday 20 March 2017 15:38:28 Ville Voutilainen wrote: > On 20 March 2017 at 16:19, Marc Mutz <marc.m...@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.m...@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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development