<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<blockquote type="cite" class="">Going forward, we should be looking into removing more and more owning containers from the interface and replace them with views. The standard is working on a solution for the stale reference problem, and by the time Qt 7 comes
 around, it will be hopefully widely available.</blockquote>
<div class=""><br class="">
</div>
This is good direction. But I would suggest something based on ranges (accepted for C++ 20 and there is already ranges-v3 on github or ranges in boost). What we should return in our API is lazy range object. This is actually a sort of view or chain of nested
 views with some conditions. If a user needs a regular container, range might be simply assigned to it. <br class="">
<div class="">
<div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;">
<br class="Apple-interchange-newline">
--</div>
<div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;">
Best Regards,<br class="">
<br class="">
Fanaskov Vitaly<br class="">
Senior Software Engineer<br class="">
<br class="">
The Qt Company / Qt Quick and Widgets Team</div>
</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 16 May 2019, at 15:05, 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="">
On 2018-11-02 08:51, Lars Knoll wrote:<br class="">
<blockquote type="cite" class="">I believe I have a solution to get rid of QList without breaking SC in<br class="">
any major way. See <a href="https://codereview.qt-project.org/#/c/242199/" class="">
https://codereview.qt-project.org/#/c/242199/</a> and<br class="">
the following changes.<br class="">
</blockquote>
[...]<br class="">
<blockquote type="cite" class="">So to re-iterate: We will not break SC in major ways. The goal is to<br class="">
make porting from Qt 5.x to 6 as easy as possible.<br class="">
</blockquote>
<br class="">
It's technically SC alright, but silently breaking the reference stability user code may rely on should be a complete no-no, considering how reluctant Qt has been since the Qt 3->4 port with disruptive changes. I welcome the openness to rethink the necessity
 of some of the plumbing infrastructure, but it appears that you have come out far on the other side on this one.<br class="">
<br class="">
As I said a few years ago, QList in Qt 5 should have a warning if it keeps reference stability (iow: if it's not already behaviour- if not structure-compatible with QVector), indicting very strongly that by Qt 6, this use-case will be gone. Then port all of
 Qt's own code away from QList, either to QVector, or, say, std::vector<std::unique_ptr>, like in QToolBox (<a href="https://codereview.qt-project.org/261943" class="">https://codereview.qt-project.org/261943</a>), which is a case where a user that actually
 relies on the implicit reference-stability guarantee of current QList, then deprecate QList.<br class="">
<br class="">
Back then I suggested to rename QList to QArrayList and have QList be a deprecated template alias for _either_ QArrayList or QVector, depending on whether Q5List would keep references stable or not.<br class="">
<br class="">
Please don't make QList an unconditional alias for QVector. You are silently breaking Qt code (cf. QToolBox) along with an unknown amount of Qt-user's code. Make the break non-silent.<br class="">
<br class="">
I understand the desire to keep old code working that was written against Qt 5. But to me, the better solution would be to have the Qt 6 API explicitly return QVector and have implicit, but deprecated, conversions between QList and QVector. The priority should
 be to not break code. It should not be a priority to have unported code enjoy optimal speed. An actual copy on implicit QVector -> QList conversion is acceptable, IMO, since the solution for codebases targeting both Qt 5 and 6 is simple: use an auto variable.<br class="">
<br class="">
Going forward, we should be looking into removing more and more owning containers from the interface and replace them with views. The standard is working on a solution for the stale reference problem, and by the time Qt 7 comes around, it will be hopefully
 widely available.<br class="">
<br class="">
Thanks for considering,<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>