> -----Original Message----- > From: Development <development-boun...@qt-project.org> On Behalf Of > André Somers > Sent: Thursday, 23 April 2020 12:04 PM > To: Jaroslaw Kobus <jaroslaw.ko...@qt.io>; development@qt-project.org > Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6 > > Hi, > > On 23-04-20 11:58, Jaroslaw Kobus wrote: > > There are cases, where the name of the function contains the "list", like: > > > > QList<QMdiSubWindow *> > QMdiArea::subWindowList(QMdiArea::WindowOrder > > order = CreationOrder) const; QList<QPair<qreal, QPointF> > > > QGraphicsItemAnimation::translationList() const; > > QList<QLowEnergyAdvertisingParameters::AddressInfo> > QLowEnergyAdvertisingParameters::whiteList() const; etc... > > > > So, subWindowList() returning the vector? > > Yeah. Not ideal, but not a big deal either in these cases, especially the last > one which uses a common term "whiteList". I do see an issue with API like > QSet::toList(). That would obviously need to be deprecated in favor of a > QSet::toVector().
QSet::toVector() was rejected in favour of range constructors: https://bugreports.qt.io/browse/QTBUG-71067 > André > > > > > > Changing QList to QVector may in consequence require even more API > changes. > > > > Jarek > > > > ________________________________________ > > From: Development <development-boun...@qt-project.org> on behalf of > > André Somers <an...@familiesomers.nl> > > Sent: Thursday, April 23, 2020 11:21 AM > > To: development@qt-project.org > > Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6 > > > > Hi Simon, > > > > > > On 23-04-20 10:55, Simon Hausmann wrote: > > Hi, > > > > So take for example this function in QIconEngine: > > > > virtual QList<QSize> availableSizes(QIcon::Mode mode = > > Icon::Normal, QIcon::State state = QIcon::Off) const; > > > > If we change that to QVector, we require our users to clutter their code > base with #ifdefs. If we keep it with QList but use QVector in all non-virtual > functions, then we create a less consistent API. > > > > Do you think the #ifdefs or inconsistency is worth the proximity to > > the standard? (despite QVector not being like std::vector due to CoW > > semantics) > > > > I may be missing the obvious, but I really fail to see the problem if > > you change the signature to > > > > virtual QVector<QSize> availableSizes(...); > > > > > > If we have that > > > > template<typename T> using QList = QVector<T>; > > > > > > a subclass reimplementing using QList should just work in both Qt5 and Qt6, > right? So what #ifdef's would be needed? > > > > > > And yes, I _do_ think staying close to the established meaning of what is a > vector and what is a list is good. Getting list of QList (which is not a > list) brings > us closer to that goal. > > > > > > André > > > > > > > > Simon > > ________________________________ > > From: Daniel Engelke > > > <daniel.enge...@basyskom.com><mailto:daniel.enge...@basyskom.com> > > Sent: Thursday, April 23, 2020 10:52 > > To: Simon Hausmann > <simon.hausm...@qt.io><mailto:simon.hausm...@qt.io> > > Cc: development@qt-project.org<mailto:development@qt-project.org> > > <development@qt-project.org><mailto:development@qt-project.org> > > Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6 > > > > Hi Simon, > > > > I think having a name that is close to the standard is very important as it > makes it easy to find the Qt counterpart. > > Back in the days I had to ask a StackOverflow question to find Qts > unique_ptr (QScopedPointer), because I couldn't find it due to the naming. > > > > Dmitriy also has a very valid point. It is burned in a lot of peoples heads > > that > using QList is a bad idea. > > > > 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. > > It's even less work if auto has been used. > > > > Dan > > > > > > From: Simon Hausmann > > <simon.hausm...@qt.io><mailto:simon.hausm...@qt.io> > > To: Dmitriy Purgin <dpur...@gmail.com><mailto:dpur...@gmail.com> > > Cc: "development@qt-project.org"<mailto:development@qt-project.org> > > <development@qt-project.org><mailto:development@qt-project.org> > > Sent: 4/23/2020 10:27 AM > > Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6 > > > > Hi Dmitriy, > > > > No, this is not an April's Foolk joke. > > > > Previous discussions were largely centred around the implementations and > bringing them together. With this thread my concern is the API and the churn > our users would have to apply to their code base in order to use Qt 5 and Qt > 6. > > > > > > Simon > > ________________________________ > > From: Dmitriy Purgin <dpur...@gmail.com><mailto:dpur...@gmail.com> > > Sent: Thursday, April 23, 2020 9:53 > > To: Simon Hausmann > <simon.hausm...@qt.io><mailto:simon.hausm...@qt.io> > > Cc: development@qt-project.org<mailto:development@qt-project.org> > > <development@qt-project.org><mailto:development@qt-project.org> > > Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6 > > > > Hi Simon, > > > > I hope it's not a belated April's Fool joke? As far as I can remember, for > > the > past few years, one would read everywhere to switch to QVector from QList > because of this and that, and to choose QVector as the default choice > container instead of QList like it was back in the days. I can't give the > exact > references but that's just the feeling I get from reading the docs and the Qt > mailing lists. > > > > Cheers > > Dmitriy > > > > On Thu, Apr 23, 2020 at 9:45 AM Simon Hausmann > <simon.hausm...@qt.io<mailto:simon.hausm...@qt.io>> wrote: > > Hi, > > > > In dev we've had QVector being an alias for QList for a while now. For the > 6.0 release this particular topic (QList/QVector) suggests two goals (among > others): > > > > (1) Use the same type throughout the public API of Qt. > > > > (2) Make it easy for our users to maintain a code base that works with > > Qt > 5 and 6. > > > > > > In the light of those two goals, I think we should keep using QList as the > type in the public API. I don't think we should do a search and replace > activity > and switch to QVector. In the light of that, I would like to propose simply > deprecating QVector and stick to QList everywhere. > > > > > > What do you think? > > > > > > Simon > > _______________________________________________ > > Development mailing list > > Development@qt-project.org<mailto:Development@qt-project.org> > > https://lists.qt-project.org/listinfo/development > > > > > > _______________________________________________ > > Development mailing list > > Development@qt-project.org<mailto:Development@qt-project.org> > > https://lists.qt-project.org/listinfo/development > > > > > > > > _______________________________________________ > > Development mailing list > > Development@qt-project.org<mailto:Development@qt-project.org> > > https://lists.qt-project.org/listinfo/development > > > _______________________________________________ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
