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