On Thu, Apr 23, 2020 at 12:48:45PM +0200, Elvis Stansvik wrote: > Den tors 23 apr. 2020 kl 11:45 skrev Laszlo Agocs <laszlo.ag...@qt.io>: > > > > That depends on the number of the functions affected, and how commonly those > > are used. If we are talking about just a few virtual functions here and > > there > > which are not expected to be overriden by a vast majority of applications > > (such as the QIconEngine example), then changing the signatures is probably > > acceptable. After all, Qt 6 will have a number of source compatibility > > breaks > > (typically in less commonly used APIs) anyways, let's have no illusions > > here. > > So on its own this should not be an argument for reprioritizing the tainted > > QList name. > > > > For years we have been teaching people to stay away from QList and treat it > > as > > a legacy thing in the API, and that it may change in a future major release. > > Any newly introduced public APIs (in the graphics-related areas at least) > > for > > the past 5-6 years are using QVector. It is odd to turn this over just like > > that. > > I have to agree with Laszlo here. The message has been that QList due to its > duality etc is problematic and may become deprecated, so we've put in work on > changing it to QVector in our code bases [...]
Was that work more than s/QList/QVector/ ? >and used QVector in newly written > code. It's a bit annoying if QList is now to become the name to be used. I'll > accept whatever is decided, but think it's a little unfortunate if we'd have > to > change all that code back to QList again. Andre' _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
