<html><head></head><body><div>> You'd need also adapt some variable and function names, <br>> comments and documentation are silently broken. </div><div><strong><br></strong></div><div>I don't really see it, unless you name all variables like qListMyList.</div><div>As for comments it's not like the logical meaning changes. Besides, QList will have QVectors implementation anyway,</div><div>making comments or variable names that focus on it being a list illogical anyhow. (Besides QList was never a list to begin with)</div><div><br></div><div>Either way you'll have the same issues with API that is using QVector. </div><div>That would need to be changed to QList to be consistent.</div><div><br></div><div>Dan</div><div><strong><br></strong></div><div><strong>From:
</strong>
 
André Pönitz <apoenitz@t-online.de>
<br>
<strong>
To:
</strong>
 
Daniel Engelke <daniel.engelke@basyskom.com>
<br>
<strong>
Cc:
</strong>
 
Simon Hausmann <Simon.Hausmann@qt.io>, "development@qt-project.org" <development@qt-project.org>
<br>
<strong>
Sent:
 
</strong>
4/23/2020 12:02 PM
<br>
<strong>
Subject:
</strong>
 
Re: [Development] Proposal: Deprecate QVector in Qt 6
<br><br><blockquote class="mori" style="margin:0 0 0 .8ex;border-left:1px solid #CCC;padding-left:1ex;">On Thu, Apr 23, 2020 at 10:52:07AM +0200, Daniel Engelke wrote:
<br>>    I don't see a lot of work in string replacing QList with QVector and
<br>>    QStringList with whatever it would be, as long as the API is
<br>>    compatible.
<br>
<br>A proper replacing is not done by replacing one type by another.
<br>
<br>You'd need also adapt some variable and function names,
<br>comments and documentation are silently broken.
<br>
<br>There's also serialization to be considered, changes to log messages,
<br>external tools operating on stringified type names, etc.
<br>
<br>This is a significant amount of work for non-trivial applications,
<br>replacing the type name scratches only the surface.
<br>
<br> 
<br>>    It's even less work if auto has been used.
<br>
<br>Not really. 'auto' saves at best the first mechanical bit concerning
<br>the type itself.  Variables, comments etc. will not be done that way 
<br>and will require manual interaction. It's very likely that this
<br>work can not be done in a lot of cases, and application will simply
<br>decide to stick to Qt 5.
<br>
<br>I am *really* happy that this proposal came up.
<br>
<br>Andre'
<br></blockquote></div></body></html>