[Development] Proposal: Deprecate QVector in Qt 6

[Mitch Curtis]

> -----Original Message-----
> From: Development <development-bounces at qt-project.org> On Behalf Of
> André Somers
> Sent: Thursday, 23 April 2020 12:04 PM
> To: Jaroslaw Kobus <Jaroslaw.Kobus at qt.io>; development at 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-bounces at qt-project.org> on behalf of
> > André Somers <andre at familiesomers.nl>
> > Sent: Thursday, April 23, 2020 11:21 AM
> > To: development at 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.engelke at basyskom.com><mailto:daniel.engelke at basyskom.com>
> > Sent: Thursday, April 23, 2020 10:52
> > To: Simon Hausmann
> <Simon.Hausmann at qt.io><mailto:Simon.Hausmann at qt.io>
> > Cc: development at qt-project.org<mailto:development at qt-project.org>
> > <development at qt-project.org><mailto:development at 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.Hausmann at qt.io><mailto:Simon.Hausmann at qt.io>
> > To: Dmitriy Purgin <dpurgin at gmail.com><mailto:dpurgin at gmail.com>
> > Cc: "development at qt-project.org"<mailto:development at qt-project.org>
> > <development at qt-project.org><mailto:development at 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 <dpurgin at gmail.com><mailto:dpurgin at gmail.com>
> > Sent: Thursday, April 23, 2020 9:53
> > To: Simon Hausmann
> <Simon.Hausmann at qt.io><mailto:Simon.Hausmann at qt.io>
> > Cc: development at qt-project.org<mailto:development at qt-project.org>
> > <development at qt-project.org><mailto:development at 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.Hausmann at qt.io<mailto:Simon.Hausmann at 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 at qt-project.org<mailto:Development at qt-project.org>
> > https://lists.qt-project.org/listinfo/development
> >
> >
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org<mailto:Development at qt-project.org>
> > https://lists.qt-project.org/listinfo/development
> >
> >
> >
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org<mailto:Development at qt-project.org>
> > https://lists.qt-project.org/listinfo/development
> >
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development