<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Hi Marc,<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 20 May 2019, at 14:39, Mutz, Marc via Development <<a href="mailto:development@qt-project.org" class="">development@qt-project.org</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">Hi Lars,<br class="">
<br class="">
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.<br class="">
<br class="">
Provided it vanishes from each and every Qt API.<br class="">
<br class="">
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.<br class="">
<br class="">
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.<br class="">
<br class="">
The way I see it:<br class="">
<br class="">
Given:<br class="">
* QList stays as-is<br class="">
* No Qt API takes or returns QList anymore, but QVector<br class="">
* QList implicitly converts to QVector, and vice versa<br class="">
* These implicit conversions are marked as deprecated<br class="">
<br class="">
Pros:<br class="">
* Old (user) code doesn't silently change the meaning<br class="">
* Old (user) code continues to work, lets users port at their own leisure<br class="">
* Receiving objects can be done with auto variables for optimal performance<br class="">
 or with QList for old code.<br class="">
* Users passing QLists into Qt APIs enjoy the implicit conversion to QVector<br class="">
 + This might be slow, but you say yourself that speed doesn't matter<br class="">
   for 95% of the code and it's easier to find and fix slow code in<br class="">
   the 5% than it is to find a silent reference stability breakage in<br class="">
   the 95%.<br class="">
<br class="">
Cons:<br class="">
* Unported code will get penalized by the implicit conversions from and to QList<br class="">
 + But using the 95/5-argument here, again: it's easier to find where the app<br class="">
   got slower in the 5% than to find a bug in the 95%.<br class="">
<br class="">
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.<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
I’m not proposing to make QList inherit QVector. Actually, I’m making it an alias to QVector. See <a href="https://codereview.qt-project.org/c/qt/qtbase/+/242692" class="">https://codereview.qt-project.org/c/qt/qtbase/+/242692</a> . </div>
<div><br class="">
</div>
<div>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</div>
<div><br class="">
</div>
<div>using QList = QVector</div>
<div><br class="">
</div>
<div>Or </div>
<div><br class="">
</div>
<div>
<div>using QList = Qt5Support::QList</div>
<div class=""><br class="">
</div>
</div>
<div>
<blockquote type="cite" class="">
<div class="">
<div class=""><br class="">
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.
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>No, of course we need to get rid of all references to QList in our APIs.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div class="">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?).<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
See above. The change where they inherit from each other is an intermediate change, not the final result.</div>
<div><br class="">
</div>
<div>Cheers,</div>
<div>Lars</div>
<div><br class="">
</div>
<div>
<blockquote type="cite" class="">
<div class="">
<div class=""><br class="">
Touché on the QStringView reference :)<br class="">
<br class="">
Thanks,<br class="">
Marc<br class="">
_______________________________________________<br class="">
Development mailing list<br class="">
<a href="mailto:Development@qt-project.org" class="">Development@qt-project.org</a><br class="">
https://lists.qt-project.org/listinfo/development<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</body>
</html>