Hi Marc, On 20 May 2019, at 14:39, Mutz, Marc via Development <development@qt-project.org<mailto:development@qt-project.org>> wrote:
Hi Lars, I'm on record for claiming QList needs to die, and I work for a company that still makes part of its living by porting Qt 3 apps to Qt 4 (and 5). So I should be celebrating if you create more potential work for KDAB, but I'm actually ok with keeping QList. Provided it vanishes from each and every Qt API. Whether to call it Q5List or QArrayList or continue with QList doesn't matter. Actually, I'd err on keeping QList, to minimize porting. What I want to avoid is to break user code silently. Asan is a runtime-checker, the code must actually be exercised, which is trivial for QToolBox but might be problematic if it's in, say, error handling code. And you rightfully pointed out that it's very hard for a static checker to find cases where reference stability is used. Not impossible, but hard. I want to understand what problems you see with keeping QList as-is with deprecated implicit conversions to and from QVector, assuming all Qt API that uses QList is ported to QVector. The way I see it: Given: * QList stays as-is * No Qt API takes or returns QList anymore, but QVector * QList implicitly converts to QVector, and vice versa * These implicit conversions are marked as deprecated Pros: * Old (user) code doesn't silently change the meaning * Old (user) code continues to work, lets users port at their own leisure * Receiving objects can be done with auto variables for optimal performance or with QList for old code. * Users passing QLists into Qt APIs enjoy the implicit conversion to QVector + This might be slow, but you say yourself that speed doesn't matter for 95% of the code and it's easier to find and fix slow code in the 5% than it is to find a silent reference stability breakage in the 95%. Cons: * Unported code will get penalized by the implicit conversions from and to QList + But using the 95/5-argument here, again: it's easier to find where the app got slower in the 5% than to find a bug in the 95%. The pros far, far outweigh the cons. I'd very much like to know in which aspects inheriting QList from QVector fares better than this proposal. I’m not proposing to make QList inherit QVector. Actually, I’m making it an alias to QVector. See https://codereview.qt-project.org/c/qt/qtbase/+/242692 . With that, one option could be to make the alias dependent on a compile time setting for the application code (ie. have a simple define whether we do using QList = QVector Or using QList = Qt5Support::QList My fear is that QList : QVector will lead to some of Qt's APIs continuing to use QList, which would lock Qt into QList for another major release cycle and only postpone the inevitable QList removal. No, of course we need to get rid of all references to QList in our APIs. C++11 gave us the tools to make this transition now much smoother than it could have been done in Qt 4->5. Inheriting QList from QVector is both technically wrong (value classes inheriting each other) and just serves to confuse users (is it still ok to use QList? Is it now suddenly ok after it wasn't in Qt 5? What do to if I target both Qt 5 and Qt 6?). See above. The change where they inherit from each other is an intermediate change, not the final result. Cheers, Lars Touché on the QStringView reference :) Thanks, Marc _______________________________________________ Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> https://lists.qt-project.org/listinfo/development
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
