[Development] Proposal: Deprecate QVector in Qt 6

[André Somers]

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>
> *Sent:* Thursday, April 23, 2020 10:52
> *To:* Simon Hausmann <Simon.Hausmann at qt.io>
> *Cc:* development at qt-project.org <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>
> *To: *Dmitriy Purgin <dpurgin at gmail.com>
> *Cc: *"development at qt-project.org" <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>
>     *Sent:* Thursday, April 23, 2020 9:53
>     *To:* Simon Hausmann <Simon.Hausmann at qt.io>
>     *Cc:* development at qt-project.org <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
>     https://lists.qt-project.org/listinfo/development
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200423/ec51a2fe/attachment.html>