Re: [Development] Proposal: Deprecate QVector in Qt 6

[Matthew Woehlke]

On 20/05/2020 13.15, Lars Knoll wrote:

On 20 May 2020, at 17:34, Matthew Woehlke wrote:

On 20/05/2020 09.11, Lars Knoll wrote:

Here’s what we will do:
* QList and QVector are aliases for each other
* We make QList the main type, and QVector an alias to it
* We keep both names, QList and QVector. None of them is deprecated


While I don't object to this as such, can someone remind me what is
the solution for people that *need* the semantics of old QList
(either reference stability or indirect allocation)?


There’s an option to provide a Q5List in qt5compat.


That's IMO a lousy option.


Of course one could also add a new class to Qt 6 that always
allocates indirectly.


This would be much better. I thought there had been talk of doing such?


But in that case I would propose to redesign it, so that is uses
block allocations to avoid at least some of the overhead of QList in
Qt 5.


That sounds like std::colony, which has different trade-offs; in 
particular, it cannot be indexed (no random access). I don't necessarily 
object to such a container type (although if we do get std::colony, 
there is less of an argument for it), but if I have to choose one, I 
would prefer to keep Qt5 QList as it was, especially as that is much 
more feasible due to the additional work of adding a new type.



Also, will the new QVector/QList have the prepend optimization of
old QList?


Yes, see https://bugreports.qt.io/browse/QTBUG-84320


Cool, thanks for the info.

--
Matthew
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Lars Knoll]

On 20 May 2020, at 17:34, Matthew Woehlke 
mailto:mwoehlke.fl...@gmail.com>> wrote:

On 20/05/2020 09.11, Lars Knoll wrote:
Here’s what we will do:
* QList and QVector are aliases for each other
* We make QList the main type, and QVector an alias to it
* We keep both names, QList and QVector. None of them is deprecated

While I don't object to this as such, can someone remind me what is the 
solution for people that *need* the semantics of old QList (either reference 
stability or indirect allocation)?

There’s an option to provide a Q5List in qt5compat.

Of course one could also add a new class to Qt 6 that always allocates 
indirectly. But in that case I would propose to redesign it, so that is uses 
block allocations to avoid at least some of the overhead of QList in Qt 5. This 
is probably something that nobody will have time to do before 6.0 though.

Also, will the new QVector/QList have the prepend optimization of old QList?

Yes, see https://bugreports.qt.io/browse/QTBUG-84320

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Matthew Woehlke]

On 20/05/2020 09.11, Lars Knoll wrote:

Here’s what we will do:

* QList and QVector are aliases for each other
* We make QList the main type, and QVector an alias to it
* We keep both names, QList and QVector. None of them is deprecated


While I don't object to this as such, can someone remind me what is the 
solution for people that *need* the semantics of old QList (either 
reference stability or indirect allocation)?


Also, will the new QVector/QList have the prepend optimization of old QList?

--
Matthew
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Aleix Pol]

On Wed, May 20, 2020 at 3:12 PM Lars Knoll  wrote:
>
> It’s been a while since Simon started this thread. I’m sure some people will 
> disagree, no matter what we do. But I’d like to conclude it, so we have one 
> solution for Qt 6.
>
> My focus is on reducing migration pain for our users and ourselves (we’ve got 
> more than enough things to finish…), as well as consistency in naming within 
> Qt.
>
> Here’s what we will do:
>
> * QList and QVector are aliases for each other
> * We make QList the main type, and QVector an alias to it
> * We keep both names, QList and QVector. None of them is deprecated
> * In Qt (code and documentation) we use QList for function arguments and 
> return types
> * QStringList is an alias to QList, ditto for QByteArrayList
> * We can extend/specialize QList for certain types through QListSpecialMethods
>
> Like that we can minimise changes in our public API between Qt 5 and Qt 6 (no 
> mass renaming from QList to QVector) and don’t have naming inconsistencies 
> with QStringList and QByteArrayList or how many of our functions are named.
>
> This is the pragmatic solution to avoid adding more pain to our users. And if 
> some of our users prefer using QVector as the name in their code, they can do 
> that without problems.
>
> I don’t think it’s a problem from an advertisement point of view neither (… 
> QList is bad, because …), as we can now simply say that we’ve fixed it for Qt 
> 6, and both QList and QVector can be used as the class name.
>
> And now I’ll get some Popcorn for the inevitable bike-shedding that’s going 
> to happen anyway :)
>
> Cheers,
> Lars
>
> On 23 Apr 2020, at 09:43, Simon Hausmann  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?

From a Qt usage perspective I'm really happy with this conclusion.
Deprecating either class was a massive change on our codebases (both
upstream Qt as well as KDE's as a Qt user and I assume every other
product that uses Qt).

Knowing that accepting a patch today that uses either will be good is
peace of mind.

It even resolves the QStringList change quite elegantly. :)

Thanks!
Aleix
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Lars Knoll]

It’s been a while since Simon started this thread. I’m sure some people will 
disagree, no matter what we do. But I’d like to conclude it, so we have one 
solution for Qt 6.

My focus is on reducing migration pain for our users and ourselves (we’ve got 
more than enough things to finish…), as well as consistency in naming within Qt.

Here’s what we will do:

* QList and QVector are aliases for each other
* We make QList the main type, and QVector an alias to it
* We keep both names, QList and QVector. None of them is deprecated
* In Qt (code and documentation) we use QList for function arguments and return 
types
* QStringList is an alias to QList, ditto for QByteArrayList
* We can extend/specialize QList for certain types through QListSpecialMethods

Like that we can minimise changes in our public API between Qt 5 and Qt 6 (no 
mass renaming from QList to QVector) and don’t have naming inconsistencies with 
QStringList and QByteArrayList or how many of our functions are named.

This is the pragmatic solution to avoid adding more pain to our users. And if 
some of our users prefer using QVector as the name in their code, they can do 
that without problems.

I don’t think it’s a problem from an advertisement point of view neither (… 
QList is bad, because …), as we can now simply say that we’ve fixed it for Qt 
6, and both QList and QVector can be used as the class name.

And now I’ll get some Popcorn for the inevitable bike-shedding that’s going to 
happen anyway :)

Cheers,
Lars

On 23 Apr 2020, at 09:43, Simon Hausmann 
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
https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Edward Welbourne]

On 4/23/20 11:10 PM, Vitaly Fanaskov wrote:
 Moving to one year release approach doesn't equal to make Qt less
 stable.

> Ville:
>>> Of course it does, if we now allow API breaks every year.

On Fri, 24 Apr 2020 at 13:38, Edward Welbourne  wrote:
>> Not necessarily: if we *allow* API breaks every year *but* are
>> restrained in our use of them - so that, in fact, over a given ten
>> year period, we only make as many API breaks; we just spread them out
>> over time more evenly - then we'd be no less stable; and it'd be
>> easier for client code maintainers to keep up with our major version
>> updates, because they'd be smaller.

Ville Voutilainen (24 April 2020 17:23)
> That is still less stable. The more frequent the API breaks are, the
> less stable the API is. The size of the API break matters as well, but
> that's easier to control; I make the decision whether to jump now or
> later, and the size of the break to a large extent affects what the
> schedule of the jump is, not that much whether to take a jump (unless
> it's so large as to be over the breaking point, of course).

But there's the catch: at present, it looks like most of our major
versions break API so much that many projects take significant time to
make the updates; converting from Qt5 to Qt6 shall be A Big Deal.  If
the API breaks were spread out over time, so that they don't all happen
at the same time, the ones that require trivial effort from a project
wouldn't bother them, they'd just take them as they go.  Those requiring
more effort will be delayed, but they'll be manageable and not mixed up
with a bunch of other API breaks, so can be handled one at a time.

The initial update of a codebase in response to a third-party library's
API changes is apt to leave some mess - various places where kludges and
short-term solutions were used to complete the update - and it takes a
few months to pay off that technical debt.  Once that's done, the
codebase is clean and orderly again - and ready to cope with the next
API change to come along.  However, if the API breaks come along at the
same time, the kludges and workarounds used to cope with one can tangle
badly with those used to cope with the other; if there's no time in
between the upheavals - because the API breaks all come in one huge load
together - that can result in a nasty snarl.  Such a snarl may be too
much to cope with by refactoring, forcing a significant rewrite, which
is when the project is going to ask itself: do we still want to continue
using this third-party library ?

> If I'd need to consider such a jump every year, I'd switch to
> something else, including changing the programming language if need
> be. Annual API breaks are untenable for any product that has a limited
> budget.

Only if those API breaks usually break the product in question.  If each
is manageable on its own - possibly after a few months of preparation
and refactoring - then the update to a new yearly release is practical
and they never drop behind by more than a year.  My limited
understanding is that, at present, many projects take a long time to
update to each new major release of Qt.  The leap is a high-jump that
some never get over and others have trouble preparing for.  Replacing it
with several modest-sized hurdles would make it possible to keep up at a
steady pace.

While yearly updates may be too frequent, I do think we could benefit
from having Qt major versions a little closer together.  When we notice
a significant API break we'll want to defer to our next major version,
we should think about how soon we can have a major release, so that its
*only* significant API break is that one, rather than saving API breaks
up to make several at the same time.

All, of course, subject to the assumption that we don't make more API
breaks per decade,

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Ville Voutilainen]

On Mon, 27 Apr 2020 at 10:10, Alberto Mardegan
 wrote:
>
> On 23/04/20 14:57, Ville Voutilainen wrote:
> > QVector is certainly closer to std::vector than QList is to std::list.
> > Vector isn't a really good name either,
> > for people recently taught in elementary school math, or for java
> > programmers coming in.
> > For C++ programmers, it gives a much better suggestion of what it is
> > than calling it QList does.
>
> This calls for a nice QArray type :-)

Arrays don't expand.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Alberto Mardegan]

On 23/04/20 14:57, Ville Voutilainen wrote:
> QVector is certainly closer to std::vector than QList is to std::list.
> Vector isn't a really good name either,
> for people recently taught in elementary school math, or for java
> programmers coming in.
> For C++ programmers, it gives a much better suggestion of what it is
> than calling it QList does.

This calls for a nice QArray type :-)

Ciao,
  Alberto

-- 
http://www.mardy.it - Geek in un lingua international
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Иван Комиссаров]

I suppose, there are plans to keep the old QList implementation under the 
different name (QArrayList/Q5List).

Can we also add the same typedef in Qt5 (using Q5List = QList)? This will 
simplify the transition for the people who want to build against Qt5 and Qt6 at 
the same time.

Ivan
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Jean-Michaël Celerier]

> I however want some generic indexable/iterable type, where it doesn't
care if the final storage is QList or  QVector... When I am working as an
API, I don't want to choose for my users what that type is and make them
pay for conversion. Which I think QList was historically the right choice.
Ideally I want to have a QIterable for processing lists/arrays/vectors. I
think the developer should be able to determine the storage best for their
application, not me.

I believe that all sort of woes come to those wanting to make C++ look more
like Java / C# with their AbstractCollection / IEnumerable ;
every time I've seen people try to go towards that path it has ended in
pain and tears and ultimately reverting to std::vector as the benefits did
not
outweight the drawbacks by a large margin.

C++20 coroutines start making that much more feasible however, like this
for instance and without creation of unnecessary temporary containers:
https://godbolt.org/z/gNsbjc
(it remains to be benchmarked whether the coroutine frame can be optimized
sufficiently well in comparison to returning a container, considering
that both clang and GCC nowadays are able to optimize out new / delete
pairs... I'd be inclined to believe that the compiler has more domain
knowledge
of the coroutine though and thus is able to make better choices).

Maybe something for Qt 8 or 9 ? :p

Best,
Jean-Michaël

On Sat, Apr 25, 2020 at 2:23 AM Jason H  wrote:

>
>
> > Sent: Friday, April 24, 2020 at 4:14 PM
> > From: "Giuseppe D'Angelo" 
> > To: "Jason H" 
> > Cc: development@qt-project.org
> > Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6
> >
> > On 4/24/20 9:03 PM, Jason H wrote:
> > >> In fact, it is-a QList. What's the problem here with its
> naming?
> > >
> > > Because I can't QSringList{"me", "you"}.join() with a QList.
> >
> > I didn't say that it's a typedef for QList, but is-a -- it
> > inherits, precisely to provide that kind of convenience.
> >
> > > Thinking outsize of the box...
> > > It seems that all this is cause d by someone wanting to store a
> pointer to an item in QVector, which may be reallocted and therfore have
> moved.
> >
> > All this => what's this?
> >
> > > It seem then that the only thing to do is to use a traditional QList,
> or return only some kind of ref which will be a stable reference to the
> item.
> > > QStableRef r9 = vector[9];
> > > vector.resize()
> > > // r9 is updated during resize() and still points to that it was meant
> to.
> > > It's not good practice to store a ref to something that can be
> realloated. I don't know how you can prevent people from doing that with
> offering T& operator[](int i);
> >
> > QList today offers exactly that. In array-of-pointers-mode it also
> > offers stability of references.
>
> Yes. I agree. I think the OP kicked this off with a thing about soring
> refs to items in QVector which is relocatable. My post was just to say this
> is a bad idea fro QVector. This is not immediately obvious though. The
> API/docs fail to communicate that storing pointers/refs to items is a bad
> idea. Which then as me agree with you and Lars's current thinking.
>
> I however want some generic indexable/iterable type, where it doesn't care
> if the final storage is QList or  QVector... When I am working as an API, I
> don't want to choose for my users what that type is and make them pay for
> conversion. Which I think QList was historically the right choice. Ideally
> I want to have a QIterable for processing lists/arrays/vectors. I think the
> developer should be able to determine the storage best for their
> application, not me.
>
> Side note:
> It also kicked off a thing in my brain about .NET and the managed runtime,
> where C++ on .NET got ^, the handle operator, which allows dereferencing to
> items given that everything is relocatable due to memory compaction. I
> think it could be a great thing if C++ has such a thing, as I attribute 99%
> of all long boot time lockups on Raspberry Pis to memory fragmentation
> (completely anecdotally) And if C/C+ could offer some kind of memory
> management beyond malloc/free, we could get the next 99% of lockups and
> random crashes avoided.
> ___
> 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

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Jason H]

> Sent: Friday, April 24, 2020 at 4:14 PM
> From: "Giuseppe D'Angelo" 
> To: "Jason H" 
> Cc: development@qt-project.org
> Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6
>
> On 4/24/20 9:03 PM, Jason H wrote:
> >> In fact, it is-a QList. What's the problem here with its naming?
> >
> > Because I can't QSringList{"me", "you"}.join() with a QList.
>
> I didn't say that it's a typedef for QList, but is-a -- it
> inherits, precisely to provide that kind of convenience.
>
> > Thinking outsize of the box...
> > It seems that all this is cause d by someone wanting to store a pointer to 
> > an item in QVector, which may be reallocted and therfore have moved.
>
> All this => what's this?
>
> > It seem then that the only thing to do is to use a traditional QList, or 
> > return only some kind of ref which will be a stable reference to the item.
> > QStableRef r9 = vector[9];
> > vector.resize()
> > // r9 is updated during resize() and still points to that it was meant to.
> > It's not good practice to store a ref to something that can be realloated. 
> > I don't know how you can prevent people from doing that with offering T& 
> > operator[](int i);
>
> QList today offers exactly that. In array-of-pointers-mode it also
> offers stability of references.

Yes. I agree. I think the OP kicked this off with a thing about soring refs to 
items in QVector which is relocatable. My post was just to say this is a bad 
idea fro QVector. This is not immediately obvious though. The API/docs fail to 
communicate that storing pointers/refs to items is a bad idea. Which then as me 
agree with you and Lars's current thinking.

I however want some generic indexable/iterable type, where it doesn't care if 
the final storage is QList or  QVector... When I am working as an API, I don't 
want to choose for my users what that type is and make them pay for conversion. 
Which I think QList was historically the right choice. Ideally I want to have a 
QIterable for processing lists/arrays/vectors. I think the developer should be 
able to determine the storage best for their application, not me.

Side note:
It also kicked off a thing in my brain about .NET and the managed runtime, 
where C++ on .NET got ^, the handle operator, which allows dereferencing to 
items given that everything is relocatable due to memory compaction. I think it 
could be a great thing if C++ has such a thing, as I attribute 99% of all long 
boot time lockups on Raspberry Pis to memory fragmentation (completely 
anecdotally) And if C/C+ could offer some kind of memory management beyond 
malloc/free, we could get the next 99% of lockups and random crashes avoided.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Giuseppe D'Angelo via Development]

On 4/24/20 9:03 PM, Jason H wrote:

In fact, it is-a QList. What's the problem here with its naming?


Because I can't QSringList{"me", "you"}.join() with a QList.


I didn't say that it's a typedef for QList, but is-a -- it 
inherits, precisely to provide that kind of convenience.



Thinking outsize of the box...
It seems that all this is cause d by someone wanting to store a pointer to an 
item in QVector, which may be reallocted and therfore have moved.


All this => what's this?


It seem then that the only thing to do is to use a traditional QList, or return 
only some kind of ref which will be a stable reference to the item.
QStableRef r9 = vector[9];
vector.resize()
// r9 is updated during resize() and still points to that it was meant to.
It's not good practice to store a ref to something that can be realloated. I don't 
know how you can prevent people from doing that with offering T& operator[](int 
i);


QList today offers exactly that. In array-of-pointers-mode it also 
offers stability of references.


Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Jason H]

> Sent: Thursday, April 23, 2020 at 12:05 PM
> From: "Giuseppe D'Angelo via Development" 
> To: development@qt-project.org
> Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6
>
> On 4/23/20 5:04 PM, Julius Bullinger wrote:
> > Another suggestion: Get rid if the aliases; use the fully-qualified
> > types instead.
> >
> > I'm always irritated if I open the documentation of QVariantList from
> > within Qt Creator, and land on the QVariant docu instead. I'm interested
> > in the features of the container, not the contained type.
>
> This is a documentation bug or a Creator bug. You're supposed to land on
> this anchor: https://doc.qt.io/qt-5/qvariant.html#QVariantList-typedef
>
> > And I have to remember if QStringList is the same as as QList,
> > or if it's actually a different container with a different API.
>
> In fact, it is-a QList. What's the problem here with its naming?


Because I can't QSringList{"me", "you"}.join() with a QList.

Thinking outsize of the box...
It seems that all this is cause d by someone wanting to store a pointer to an 
item in QVector, which may be reallocted and therfore have moved.
It seem then that the only thing to do is to use a traditional QList, or return 
only some kind of ref which will be a stable reference to the item.
QStableRef r9 = vector[9];
vector.resize()
// r9 is updated during resize() and still points to that it was meant to.
It's not good practice to store a ref to something that can be realloated. I 
don't know how you can prevent people from doing that with offering T& 
operator[](int i);



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Thiago Macieira]

On Thursday, 23 April 2020 08:04:27 PDT Julius Bullinger wrote:
> And I have to remember if QStringList is the same as as QList,
> or if it's actually a different container with a different API.

In Qt 5 it is a different type with extra API. In Qt 6, those extra methods 
should move to an extra base class of QList/QVector (QLisstSpecialMethods) so 
it is an actual QList. Ditto for QList.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[NIkolai Marchenko]

>  But if the majority thinks that the class name is burned
Majority of whom? I am fairly certain most Qt developers either didn't know
about QList controversy or didn't care about it enough to consider it in
their code.
The only people who care are ones in this mailing list most likely. Imo.

On Fri, Apr 24, 2020 at 7:36 PM Joerg Bornemann 
wrote:

> On 4/24/20 18:10, Giuseppe D'Angelo via Development wrote:
> > On 4/24/20 8:57 AM, Joerg Bornemann wrote:
> >>
> >> Alternatively, proposal 3 (aka "do almost nothing"):
> >>   template  class QVector { implementation }
> >>   template  using QList = QVector;
> >>
> >> No deprecation of QVector.
> >> No replacement of QList with QVector in our API.
> >>
> >> Rationale: QList is our default sequential container, and in Qt6 we just
> >> change its implementation.
> >
> > Could you please argument a bit more? In particular:
> >
> > * Is it OK to live with a mixup of containers in the APIs? What's the
> > downside in terms of consistency, teachability, learning, etc.?
>
> No, IMO it's not OK to have a mix of QVector/QList in our public APIs.
> Most of the time the user is interested in the fact that they have to
> pass or get sequence of items. Be it QVector, QList or something else.
>
> We should settle on one type and use it consistently.
> Historically, QList was this general purpose container.
>
> > * If I'm adding a new function, what would the coding guideline be,
> > take/return QList or QVector? Why?
>
> Use the agreed-on general purpose container of Qt. If you use another
> container, have a good reason.
> Why? Consistency.
>
> > * What's the reason against the replacement? It's not worth it in terms
> > of manpower, or another guideline?
>
> I'm not strongly against the replacement. I'm strongly against the
> deprecation. If QList==QVector I really don't care about the
> replacement. But I, personally, wouldn't invest in changing every
> occurrence of QList to QVector. I really don't see the benefit.
>
> IMHO, we can keep using QList. The only thing we have to do is to
> communicate the fact that QList's implementation has been fixed/adjusted
> to current requirements for Qt6. But if the majority thinks that the
> class name is burned, so be it. Use QVector in the API and replace like
> there's no tomorrow. But don't deprecate QList or QVector as this will
> be a heavy burden for projects migrating from Qt5 to 6 or projects that
> - God forbid - support both versions.
>
>
> Stay healthy,
>
> Joerg
> ___
> 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

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Joerg Bornemann]

On 4/24/20 18:10, Giuseppe D'Angelo via Development wrote:

On 4/24/20 8:57 AM, Joerg Bornemann wrote:


Alternatively, proposal 3 (aka "do almost nothing"):
  template  class QVector { implementation }
  template  using QList = QVector;

No deprecation of QVector.
No replacement of QList with QVector in our API.

Rationale: QList is our default sequential container, and in Qt6 we just
change its implementation.


Could you please argument a bit more? In particular:

* Is it OK to live with a mixup of containers in the APIs? What's the 
downside in terms of consistency, teachability, learning, etc.?


No, IMO it's not OK to have a mix of QVector/QList in our public APIs. 
Most of the time the user is interested in the fact that they have to 
pass or get sequence of items. Be it QVector, QList or something else.


We should settle on one type and use it consistently.
Historically, QList was this general purpose container.

* If I'm adding a new function, what would the coding guideline be, 
take/return QList or QVector? Why?


Use the agreed-on general purpose container of Qt. If you use another 
container, have a good reason.

Why? Consistency.

* What's the reason against the replacement? It's not worth it in terms 
of manpower, or another guideline?


I'm not strongly against the replacement. I'm strongly against the 
deprecation. If QList==QVector I really don't care about the 
replacement. But I, personally, wouldn't invest in changing every 
occurrence of QList to QVector. I really don't see the benefit.


IMHO, we can keep using QList. The only thing we have to do is to 
communicate the fact that QList's implementation has been fixed/adjusted 
to current requirements for Qt6. But if the majority thinks that the 
class name is burned, so be it. Use QVector in the API and replace like 
there's no tomorrow. But don't deprecate QList or QVector as this will 
be a heavy burden for projects migrating from Qt5 to 6 or projects that 
- God forbid - support both versions.



Stay healthy,

Joerg
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Giuseppe D'Angelo via Development]

On 4/24/20 8:57 AM, Joerg Bornemann wrote:


Alternatively, proposal 3 (aka "do almost nothing"):
  template  class QVector { implementation }
  template  using QList = QVector;

No deprecation of QVector.
No replacement of QList with QVector in our API.

Rationale: QList is our default sequential container, and in Qt6 we just
change its implementation.


Could you please argument a bit more? In particular:

* Is it OK to live with a mixup of containers in the APIs? What's the 
downside in terms of consistency, teachability, learning, etc.?


* If I'm adding a new function, what would the coding guideline be, 
take/return QList or QVector? Why?


* What's the reason against the replacement? It's not worth it in terms 
of manpower, or another guideline?


Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Ville Voutilainen]

On Fri, 24 Apr 2020 at 13:58, Edward Welbourne  wrote:
>
> Giuseppe D'Angelo (24 April 2020 10:19) asked
> >>> Which "one year release approach" are we talking about here?
>
> On 4/24/20 12:36 PM, Edward Welbourne wrote:
> >> That would be Vitaly's proposal to have major releases yearly.
>
> Giuseppe D'Angelo (April 24, 2020 12:38)
> > I must be missing something: how would that help, regarding the
> > problem at hand? In other words, how does such a decision influence
> > the solution of the problem?
>
> Vitaly favours getting rid of QList in Qt6 and providing tools to
> automate conversion.  Some of us will only consider this a credible
> option when we see those tools in operation.  Quite how the faster major
> release cycle would bear on this, I must leave Vitaly to answer.

Unless there are conversion tools that can convert back and forth, this approach
will never work. The fairytale of automatic conversion that is usually
spun fails
to even consider this, and it tends to be so that even the half-assed half of
the conversion fails to materialize, let alone the other half that is
an absolute must
for such a conversion to be a feasible solution to migration over an API break.
Otherwise the maintenance cost of targeting two incompatible sides of the API
fence is still doubled.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Ville Voutilainen]

On Fri, 24 Apr 2020 at 13:38, Edward Welbourne  wrote:
>
> On 4/23/20 11:10 PM, Vitaly Fanaskov wrote:
> >> Moving to one year release approach doesn't equal to make Qt less stable.
>
> Ville:
> > Of course it does, if we now allow API breaks every year.
>
> Not necessarily: if we *allow* API breaks every year *but* are
> restrained in our use of them - so that, in fact, over a given ten year
> period, we only make as many API breaks; we just spread them out over
> time more evenly - then we'd be no less stable; and it'd be easier for
> client code maintainers to keep up with our major version updates,
> because they'd be smaller.

That is still less stable. The more frequent the API breaks are, the
less stable the API
is. The size of the API break matters as well, but that's easier to
control; I make the decision
whether to jump now or later, and the size of the break to a large
extent affects what the schedule
of the jump is, not that much whether to take a jump (unless it's so
large as to be over the breaking
point, of course). If I'd need to consider such a jump every year, I'd switch to
something else, including changing the programming language if need
be. Annual API
breaks are untenable for any product that has a limited budget.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Matthew Woehlke]

On 24/04/2020 07.51, André Pönitz wrote:

So what is left is the question about what is in the name. That question was
interestingly enough not present at the begin of the crusade, it only came up
after it turned out that blind replacement of QList by QVector wasn't *that*
trivial and actually caused performance regressions in real world applications,
i.e. the performance argument made against QList wasn't quite as uniformly
applicable as initially presented.


Hear, hear! And this is why I keep asking that we not get rid of Qt5 
QList (even if we a) call it something else and b) get rid of the 
sometimes-optimization of direct storage). Sometimes, it *is* the right 
tool for the job.


--
Matthew
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Иван Комиссаров]

+1 for proposal 3.

I don’t see any reason to repeat all the arguments against the original 
proposal, I cannot agree more.

Ivan

> 24 апр. 2020 г., в 08:57, Joerg Bornemann  написал(а):
> 
> On 4/23/20 15:52, Thiago Macieira wrote:
> 
>>> Proposed:
>>> 
>>> template  using QVector = QList; // mark deprecated
>>> template  class QList { $(implementation to be moved); }
>> Proposal 2:
>> template  class QList { $(implementation to be moved); }
>> template  using QVector = QList;
>> no deprecation.
> 
> +1 for proposal 2.
> 
> Alternatively, proposal 3 (aka "do almost nothing"):
>template  class QVector { implementation }
>template  using QList = QVector;
> 
> No deprecation of QVector.
> No replacement of QList with QVector in our API.
> 
> Rationale: QList is our default sequential container, and in Qt6 we just 
> change its implementation.
> 
> The "people have been told many times to not use QList" argument can be 
> countered with "this has been fixed in Qt6".
> 
> The "vector is a silly name from a mathematical standpoint" argument is 
> valid, but vector is an established term in C++ world. Sorry, that ship has 
> sailed.
> 
> 
> Cheers,
> 
> Joerg
> ___
> 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

Re: [Development] Proposal: Deprecate QVector in Qt 6

[André Pönitz]

On Fri, Apr 24, 2020 at 09:33:49AM +0200, Christian Ehrlicher wrote:
> Am 24.04.2020 um 09:22 schrieb Lars Knoll:
> > > e "vector is a silly name from a mathematical standpoint" argument is 
> > > valid,
> > > but vector is an established term in C++ world. Sorry, that ship has 
> > > sailed.
> > > I am also in favor of proposal 2 or 3. I think deprecating either QList or
> > > QVector without any big advantage for the user will just make porting form
> > > Qt5 to Qt6 needlessly harder.
> > > 
> > > Even inside Qt we are struggling to keep up with deprecation warnings
> > > (Thanks to Friedemann for fixing these). I am pretty sure Creator does 
> > > have
> > > the same "problem". Extrapolating that from "just us" to the broader
> > > audience we are hopefully targetting, it looks like lots of
> > > users/applications will be hit by these warnings and it will mean (lots 
> > > of?)
> > > work for them.
> > I do agree that we shouldn’t deprecate neither name, as that would just make
> > moving from 5 to 6 harder. The unification of the classes should help 
> > simplify
> > things.
> > 
> > But we need to have a consistent message around which name is the preferred
> > one and used in Qt’s own API and documentation. Having a QList in one method
> > and a QVector in the next one would only be confusing to our users. So IMO
> > this thread should mainly be about deciding what the default name for this
> > container is in our documentation and API in Qt 6.
>
> Since you tell everyone since ages that QList should not be used (it's in the
> documentation since 5.6: 
> https://doc-snapshots.qt.io/qt5-5.9/qlist.html#details

Sorry. There was never an *agreement* on the issue.

QList(<=5) was designed and implemented to be a convenient, easy-to-use
one-size-fits-all container for use cases in user facing application that was
hard to completely get wrong even for C++ newbies, including "unreasonable" use
cases like being able to access by index *and* to insert big objects in the
middle without completely killing performance.

It was never meant to be the best performing nor the smallest container for a
given fixed use case *by design*.

Consequently, it was very easy to find setups were there where better
alternatives. In fact, in almost all setups there was *some* other container
that was smaller or faster, it was "just" not always the same container.

From that some people draw the conclusion that QList was a bad thing and started
lobbying for its demise in blog posts, conference talks and here on the mailing
list. Over time this was successful, at some time in the documentation the
comment on the default choice was flipped and for Qt 6 the implementation was
shared with QVector.

For this discussion here now the interesting consequence is that by the new
sharing of the implementation with QVector all the implementation related
arguments against QList that have been made in the past are void, all those
arguments do *not* apply to QList(>=6), at least not unless you extend them to
QVector, see below.

When you now look at the 2010 blog post you'll notice that *none* of the
performance and size claims in there apply to QList(>=6).


So what is left is the question about what is in the name. That question was
interestingly enough not present at the begin of the crusade, it only came up
after it turned out that blind replacement of QList by QVector wasn't *that*
trivial and actually caused performance regressions in real world applications,
i.e. the performance argument made against QList wasn't quite as uniformly
applicable as initially presented.

Today the main line of reasoning given is that QVector is something like
std::vector and people knowing C++ would feel comfortable using it the same way.

And that would be a false friend.

QVector is refcounted, so it *also* trades cycles (e.g. for write access) for
convenience (return by value without further decoration? No problem!) This is
still exactly the same quality of compromise QList was accused of for a decade
now, all the arguments made against compromises in principle could be made
against QVector as well.

Replacing *now* all QList uses by QVector would be a lose-lose situation. People
aiming at the ability to use a std:: container of their choice will not be
content, as it's still not a std:: container, both in name and behaviour.
Everyone else will have to adapt their code or live with the uncomfortable
feeling about not using the most recent name.

It's still possible, and easy, to limit the damage to one of the factions,
and that's what I understand is what the proposals here were aiming at.

Andre'
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Edward Welbourne]

Giuseppe D'Angelo (24 April 2020 10:19) asked
>>> Which "one year release approach" are we talking about here?

On 4/24/20 12:36 PM, Edward Welbourne wrote:
>> That would be Vitaly's proposal to have major releases yearly.

Giuseppe D'Angelo (April 24, 2020 12:38)
> I must be missing something: how would that help, regarding the
> problem at hand? In other words, how does such a decision influence
> the solution of the problem?

Vitaly favours getting rid of QList in Qt6 and providing tools to
automate conversion.  Some of us will only consider this a credible
option when we see those tools in operation.  Quite how the faster major
release cycle would bear on this, I must leave Vitaly to answer.

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Edward Welbourne]

Giuseppe said:
 First and foremost, we have a problem of coding guidelines, which
 demand simple pluralization of the entity returned, not "List"
 suffixing:

and conforming with that would fix the *List naming problem, so by all
means let's do that during the lifetime of Qt6, deprecating *List names
in favour of plural replacements.  Too late to do it at th Qt5/Qt6
transition though, so we may as well take our time.

 The major problem in this department has to do with caring that
 something is actually a vector (contiguous in memory, etc.) rather
 than just a sequence implemented "somehow" (... as efficiently as
 possible, this is C++ after all).

If "list" means opaque sequential container and "vector" means a
packaged array, whose contents it makes sense to ask for as .data(),
then that could be a reasonable guidline for when to use which of the
types; use QList to discourage all but iteration of the container, use
QVector to invite grungy low-level access.

On 4/23/20 15:52, Thiago Macieira wrote:
>>> I am also in favor of proposal 2 or 3. I think deprecating either
>>> QList or QVector without any big advantage for the user will just
>>> make porting form Qt5 to Qt6 needlessly harder.
>>>
>>> Even inside Qt we are struggling to keep up with deprecation
>>> warnings (Thanks to Friedemann for fixing these). I am pretty sure
>>> Creator does have the same "problem". Extrapolating that from "just
>>> us" to the broader audience we are hopefully targetting, it looks
>>> like lots of users/applications will be hit by these warnings and it
>>> will mean (lots of?) work for them.

Am 24.04.2020 um 09:22 schrieb Lars Knoll:
>> I do agree that we shouldn’t deprecate neither name, as that would
>> just make moving from 5 to 6 harder. The unification of the classes
>> should help simplify things.
>>
>> But we need to have a consistent message around which name is the
>> preferred one and used in Qt’s own API and documentation. Having a
>> QList in one method and a QVector in the next one would only be
>> confusing to our users. So IMO this thread should mainly be about
>> deciding what the default name for this container is in our
>> documentation and API in Qt 6.

Christian Ehrlicher (24 April 2020 09:33)
> Since you tell everyone since ages that QList should not be used (...)
> and the discrepancy between std::list and QList I don't understand
> what's to be discussed here at all.

Mainly the scale of the change.  Users of Qt are used to the
discrepancy, and a global s/List/Vector/ is seen as too disruptive,
simply because we use QList so pervasively.

If we keep both names, for the one thing, we can gradully make the
transition from one to the other; changing the name of the return-type
of a function won't change the actual API or ABI, so can be done freely,
although changing the *name* of the function will - but, as Giuseppe
points out, the name shouldn't have "List" or "Vector" in it anyway, it
should be a plural.

So if we make one type an alias for the other we don't force any change
on anyone, but we allow ourselves to change which name we use in new
code and convert old code to the extent that we can be bothered.  That
then leaves the question of which name we should use, as Lars says.  I
think consistency with the rest of the C++ universe does make a
compelling argument for QVector.

Fortunately, we don't need to rush; we have the whole lifetime of Qt6 to
make the transition,

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Giuseppe D'Angelo via Development]

On 4/24/20 12:36 PM, Edward Welbourne wrote:


Giuseppe D'Angelo (24 April 2020 10:19) asked

Which "one year release approach" are we talking about here?

That would be Vitaly's proposal to have major releases yearly.


I must be missing something: how would that help, regarding the problem 
at hand? In other words, how does such a decision influence the solution 
of the problem?


Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Edward Welbourne]

On 4/23/20 11:10 PM, Vitaly Fanaskov wrote:
>> Moving to one year release approach doesn't equal to make Qt less stable.

Ville:
> Of course it does, if we now allow API breaks every year.

Not necessarily: if we *allow* API breaks every year *but* are
restrained in our use of them - so that, in fact, over a given ten year
period, we only make as many API breaks; we just spread them out over
time more evenly - then we'd be no less stable; and it'd be easier for
client code maintainers to keep up with our major version updates,
because they'd be smaller.

Of course, whether we actually *would* exercise that restraint is an
open question; I have my doubts.

Giuseppe D'Angelo (24 April 2020 10:19) asked
> Which "one year release approach" are we talking about here?

That would be Vitaly's proposal to have major releases yearly.

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Giuseppe D'Angelo via Development]

On 4/23/20 11:10 PM, Vitaly Fanaskov wrote:


How often do you think we can play this game until people look for
something they consider more stable?

Moving to one year release approach doesn't equal to make Qt less stable.


Which "one year release approach" are we talking about here?

Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Christian Ehrlicher]

Am 24.04.2020 um 09:22 schrieb Lars Knoll:

e "vector is a silly name from a mathematical standpoint" argument is valid, 
but vector is an established term in C++ world. Sorry, that ship has sailed.
I am also in favor of proposal 2 or 3. I think deprecating either QList or 
QVector without any big advantage for the user will just make porting form Qt5 
to Qt6 needlessly harder.

Even inside Qt we are struggling to keep up with deprecation warnings (Thanks to Friedemann for 
fixing these). I am pretty sure Creator does have the same "problem". Extrapolating that 
from "just us" to the broader audience we are hopefully targetting, it looks like lots of 
users/applications will be hit by these warnings and it will mean (lots of?) work for them.

I do agree that we shouldn’t deprecate neither name, as that would just make 
moving from 5 to 6 harder. The unification of the classes should help simplify 
things.

But we need to have a consistent message around which name is the preferred one 
and used in Qt’s own API and documentation. Having a QList in one method and a 
QVector in the next one would only be confusing to our users. So IMO this 
thread should mainly be about deciding what the default name for this container 
is in our documentation and API in Qt 6.

Since you tell everyone since ages that QList should not be used (it's
in the documentation since 5.6:
https://doc-snapshots.qt.io/qt5-5.9/qlist.html#details , Marc wrote
about not using QList in 2010 ) and the discrepancy between std::list
and QList I don't understand what's to be discussed here at all.


Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Lars Knoll]

> On 24 Apr 2020, at 09:11, Oliver Wolff  wrote:
> 
> Hi
> 
> On 24.04.2020 08:57, Joerg Bornemann wrote:
>> On 4/23/20 15:52, Thiago Macieira wrote:
 Proposed:
 
  template  using QVector = QList; // mark deprecated
  template  class QList { $(implementation to be moved); }
>>> 
>>> Proposal 2:
>>> 
>>>  template  class QList { $(implementation to be moved); }
>>>  template  using QVector = QList;
>>> 
>>> no deprecation.
>> +1 for proposal 2.
>> Alternatively, proposal 3 (aka "do almost nothing"):
>> template  class QVector { implementation }
>> template  using QList = QVector;
>> No deprecation of QVector.
>> No replacement of QList with QVector in our API.
>> Rationale: QList is our default sequential container, and in Qt6 we just 
>> change its implementation.
>> The "people have been told many times to not use QList" argument can be 
>> countered with "this has been fixed in Qt6".
>> The "vector is a silly name from a mathematical standpoint" argument is 
>> valid, but vector is an established term in C++ world. Sorry, that ship has 
>> sailed.
> 
> I am also in favor of proposal 2 or 3. I think deprecating either QList or 
> QVector without any big advantage for the user will just make porting form 
> Qt5 to Qt6 needlessly harder.
> 
> Even inside Qt we are struggling to keep up with deprecation warnings (Thanks 
> to Friedemann for fixing these). I am pretty sure Creator does have the same 
> "problem". Extrapolating that from "just us" to the broader audience we are 
> hopefully targetting, it looks like lots of users/applications will be hit by 
> these warnings and it will mean (lots of?) work for them.

I do agree that we shouldn’t deprecate neither name, as that would just make 
moving from 5 to 6 harder. The unification of the classes should help simplify 
things. 

But we need to have a consistent message around which name is the preferred one 
and used in Qt’s own API and documentation. Having a QList in one method and a 
QVector in the next one would only be confusing to our users. So IMO this 
thread should mainly be about deciding what the default name for this container 
is in our documentation and API in Qt 6.

Cheers,
Lars



> 
> Cheers,
> Olli
> 
> 
>> Cheers,
>> Joerg
>> ___
>> 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

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Oliver Wolff]

Hi

On 24.04.2020 08:57, Joerg Bornemann wrote:

On 4/23/20 15:52, Thiago Macieira wrote:


Proposed:

 template  using QVector = QList; // mark deprecated
 template  class QList { $(implementation to be 
moved); }


Proposal 2:

 template  class QList { $(implementation to be moved); }
 template  using QVector = QList;

no deprecation.


+1 for proposal 2.

Alternatively, proposal 3 (aka "do almost nothing"):
     template  class QVector { implementation }
     template  using QList = QVector;

No deprecation of QVector.
No replacement of QList with QVector in our API.

Rationale: QList is our default sequential container, and in Qt6 we just 
change its implementation.


The "people have been told many times to not use QList" argument can be 
countered with "this has been fixed in Qt6".


The "vector is a silly name from a mathematical standpoint" argument is 
valid, but vector is an established term in C++ world. Sorry, that ship 
has sailed.




I am also in favor of proposal 2 or 3. I think deprecating either QList 
or QVector without any big advantage for the user will just make porting 
form Qt5 to Qt6 needlessly harder.


Even inside Qt we are struggling to keep up with deprecation warnings 
(Thanks to Friedemann for fixing these). I am pretty sure Creator does 
have the same "problem". Extrapolating that from "just us" to the 
broader audience we are hopefully targetting, it looks like lots of 
users/applications will be hit by these warnings and it will mean (lots 
of?) work for them.


Cheers,
Olli




Cheers,

Joerg
___
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

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Joerg Bornemann]

On 4/23/20 15:52, Thiago Macieira wrote:


Proposed:

 template  using QVector = QList; // mark deprecated
 template  class QList { $(implementation to be moved); }


Proposal 2:

 template  class QList { $(implementation to be moved); }
 template  using QVector = QList;

no deprecation.


+1 for proposal 2.

Alternatively, proposal 3 (aka "do almost nothing"):
template  class QVector { implementation }
template  using QList = QVector;

No deprecation of QVector.
No replacement of QList with QVector in our API.

Rationale: QList is our default sequential container, and in Qt6 we just 
change its implementation.


The "people have been told many times to not use QList" argument can be 
countered with "this has been fixed in Qt6".


The "vector is a silly name from a mathematical standpoint" argument is 
valid, but vector is an established term in C++ world. Sorry, that ship 
has sailed.



Cheers,

Joerg
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Ville Voutilainen]

On Fri, 24 Apr 2020 at 00:13, Vitaly Fanaskov  wrote:
> How often do you think we can play this game until people look for
> something they consider more stable?
>
> Moving to one year release approach doesn't equal to make Qt less stable.

Of course it does, if we now allow API breaks every year.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Vitaly Fanaskov]

One year for a major Qt release and then break API?
I didn't say that.
The thing is that there will be much less changes for one year. It means that 
you need to do less job to switch a version. I hope it also will lead to more 
careful feature planning and API design. With shorter release cycle it also 
will be possible to faster adopt new best practices, approaches, and language 
standards. Especially for new API. All of these things make developers more 
productive and make it easier to hire a new people.
Just think when Qt and its user could make use of such a handy things like 
coroutines, ranges, modules, concepts and so on. In 3-5 years, with the current 
approach. Probably. These features is not something trendy, they are the real 
things that help solving regular software engineering tasks faster and more 
efficient.

How many people have you seen that use Qt as a means to get *their*
problem solved, and how many of them prefered adapting their code to
Qt API changes over working on there own code?
I guess this is a rhetorical question, right? The situation is the same with a 
refactoring. There are many books about it. All I want to say is that there is 
always should be a balance.

How often do you think we can play this game until people look for
something they consider more stable?
Moving to one year release approach doesn't equal to make Qt less stable.


From: André Pönitz 
Sent: Thursday, April 23, 2020 17:52
To: Vitaly Fanaskov 
Cc: Simon Hausmann ; development@qt-project.org 

Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

On Thu, Apr 23, 2020 at 12:25:33PM +, Vitaly Fanaskov wrote:
>I think we should completely remove QList in Qt6. It was planned
>before, as far as I remember. The main reason is to be consistent with
>STL wording and do not violate POLA too much.
>
>I read the entire discussion, and I'd like to say this one more time:
>we don't have to fight the consequences. Better to eliminate a cause.
>There always will be a functionality to deprecate. There always will be
>controversial APIs, that, for example, contain a hard-coded type
>information in the name (e.g. "windowList()" instead of "windows()").
>Why not think about it instead? Today it QVector vs. QList, tomorrow
>something else...
>
>We can at least shorten release cycle to one year.

One year for a major Qt release and then break API?

How many people have you seen that use Qt as a means to get *their*
problem solved, and how many of them prefered adapting their code to
Qt API changes over working on there own code?

How often do you think we can play this game until people look for
something they consider more stable?

>Provide clang-based tools to (semi-)automatically port users' code
>bases to a new version of Qt.
>
>These tools might either fix a code or at
>least add a comment in potentially problematic places where a user
>should correct the code. A developer who changes API should also
>implement a rule for these tools.

This magic tool comes up over and over again, still no-one "just did it".
Maybe because it's not *that* trivial after all, maybe because doing that
actual porting ends up in real work, which is  much less fun than just
deciding that something needs to be changed, maybe something else.

Really: All this talk "this is bad, should be done differently, and
then it is better" would be much easier to believe if they were accompanied
by patches that implements that change for all of Qt. Or all of KDE.

Andre'
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Manuel Bergler]

Am Do., 23. Apr. 2020 um 21:01 Uhr schrieb Giuseppe D'Angelo via
Development :
>
> On 4/23/20 6:54 PM, Manuel Bergler wrote:
> >> This is a documentation bug or a Creator bug. You're supposed to land on
> >> this anchor:https://doc.qt.io/qt-5/qvariant.html#QVariantList-typedef
> > Technically this is the correct place to land on, but it isn't
> > helpful. Just like Julius, if I have a container most of the time I
> > care about the API of the container, not about the API of the
> > value_type.  So I expect to see the API for that container when I open
> > the documentation, but when intuitively scrolling up to the list of
> > member functions it sometimes takes several seconds for me to realize
> > that I landed on the QVariant page instead. If it were written as
> > QList I could choose to either open the documentation for
> > QVariant or for QList.
>
> This is still a suggestion for Qt Creator, though. Note that the link
> above contains links to both QList and QVariant.

I am aware of that. But by the time I realize I have the documentation
for the wrong type I'm no longer at that place. The way I tend to use
the documentation is for exploration of the API, so the very first
thing I always do is to scroll to the list of member functions. I
don't even bother reading where I initially ended up in the
documentation. So as soon as I open the documentation for QVariantList
I scroll to the top until I reach the member function list. And then I
notice that some of these don't seem right, and I realize I'm looking
at the documentation for QVariant even though I need the one for
QList. But at that point it is too late. And it happens every time,
because that way to use the documentation is so habitual simply
because it works in 99% of the cases.

>
> >
> >>> And I have to remember if QStringList is the same as as QList,
> >>> or if it's actually a different container with a different API.
> >> In fact, it is-a QList. What's the problem here with its naming?
> > The issue is that Qt itself is not consistent with the naming.
> > QStringList is just an alias for QList, but e.g. QDomNodeList
> > (https://doc.qt.io/qt-5/qdomnodelist.html) isn't. So unless you've
> > frequently used the particular type you always have to look it up. If
> > it were spelled as QList it'd be obvious.
> >
>
> This is:
>
> 1) an indication that by using "List" in the type name we don't actually
> mean QList, but we mean "sequence of"; and/or
> 2) an API mistake.

I agree it is an API mistake, but that doesn't change the situation
that the existence of that API makes it so that I cannot be sure
whether something that ends in "List" is a typedef or its own type and
I have to look it up every time. If the aliases were deprecated and
the full type were used instead, then in the majority of cases I don't
have to look it up because it is spelled out and I know the API of
QList. Only in the few remaining cases where a type ending in "List"
I'd have to look it up to check whether this is one of the old aliases
or a separate type. Another case that comes to mind that I have to
look up every time: QVariantMap. I always forget what the key type is
because I use it so infrequently.

>
> Thanks,
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
>
> ___
> 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

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Matthew Woehlke]

On 23/04/2020 10.45, Giuseppe D'Angelo via Development wrote:
(Otherwise, "list" in Python is heterogeneous, why isn't QList 
heterogeneous?)


That doesn't count; *variables* in Python are heterogeneous.

  a = 5  # type(a) == int
  a = 'foo'  # type(a) == str

It should not surprise one that containers in a strongly typed language 
are exactly as homogeneous as any other variable is strongly typed. 
(That is, unless the "type" is actually a type-erasure type such as 
QVariant.)


--
Matthew
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Giuseppe D'Angelo via Development]

On 4/23/20 6:54 PM, Manuel Bergler wrote:

This is a documentation bug or a Creator bug. You're supposed to land on
this anchor:https://doc.qt.io/qt-5/qvariant.html#QVariantList-typedef

Technically this is the correct place to land on, but it isn't
helpful. Just like Julius, if I have a container most of the time I
care about the API of the container, not about the API of the
value_type.  So I expect to see the API for that container when I open
the documentation, but when intuitively scrolling up to the list of
member functions it sometimes takes several seconds for me to realize
that I landed on the QVariant page instead. If it were written as
QList I could choose to either open the documentation for
QVariant or for QList.


This is still a suggestion for Qt Creator, though. Note that the link 
above contains links to both QList and QVariant.





And I have to remember if QStringList is the same as as QList,
or if it's actually a different container with a different API.

In fact, it is-a QList. What's the problem here with its naming?

The issue is that Qt itself is not consistent with the naming.
QStringList is just an alias for QList, but e.g. QDomNodeList
(https://doc.qt.io/qt-5/qdomnodelist.html) isn't. So unless you've
frequently used the particular type you always have to look it up. If
it were spelled as QList it'd be obvious.



This is:

1) an indication that by using "List" in the type name we don't actually 
mean QList, but we mean "sequence of"; and/or

2) an API mistake.

Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Matthew Woehlke]

On 23/04/2020 05.30, Ville Voutilainen wrote:

On Thu, 23 Apr 2020 at 12:25, Philippe wrote:

QList is historically a cause of ambiguity, and Qt6 is the chance to get rid of 
that.


Indeed. In Qt5, QList is sometimes a list,
sometimes a vector, but in Qt6 it's never a list.


Correction: in Qt5, it is sometimes a vector, and sometimes a 
vector-like container that uses indirect storage. It is never a linked 
list (although the latter may be somewhat more list-like than vector-like).


...and are we just missing that container type in Qt6?


I would think the better approach would be to keep dev as it is, and
deprecate and eventually remove QList.
Can we please *not* get rid of a useful container type that has no STL 
equivalent?


--
Matthew
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[André Pönitz]

On Thu, Apr 23, 2020 at 04:45:02PM +0200, Giuseppe D'Angelo via Development 
wrote:
> On 4/23/20 1:20 PM, Edward Welbourne wrote:
> > So how much harm does it really cause, to keep both names; and use
> > whichever feels like the more natural description of the value one is
> > returning ?
> 
> I missing the bigger picture about this thread. What are we trying to assess
> / solve?

I am not sure what everyone else is trying to solve, but I know
what I am trying to solve.

I am trying to solve the problem that moving an application from
Qt 5 to 6 will require significant effort, arguably too much effort
already for, so we'll see a lot of applications reluctantly,
or possibly never, moving to Qt 6, effectively dropping out.

And I think that's a situation nobody here should be interested in.

Solving the QList issue by saying "nothing to be done" takes
away some part of the pressure, specifically one that has the
potential of touching a large part of a code base.
 
> If we went the other way around, i.e. QList is the "default" type, like
> proposed: doesn't the task stay fundamentally the same?

No, because there's a lot less code using QVector, and from that
quite a bit only introduced recently, i.e. in an context where
one can hope that the projects actually have active resources
to "fix" things.

> [...]

Andre'
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Manuel Bergler]

Am Do., 23. Apr. 2020 um 18:07 Uhr schrieb Giuseppe D'Angelo via
Development :
>
> On 4/23/20 5:04 PM, Julius Bullinger wrote:
> > Another suggestion: Get rid if the aliases; use the fully-qualified
> > types instead.
> >
> > I'm always irritated if I open the documentation of QVariantList from
> > within Qt Creator, and land on the QVariant docu instead. I'm interested
> > in the features of the container, not the contained type.
>
> This is a documentation bug or a Creator bug. You're supposed to land on
> this anchor: https://doc.qt.io/qt-5/qvariant.html#QVariantList-typedef

Technically this is the correct place to land on, but it isn't
helpful. Just like Julius, if I have a container most of the time I
care about the API of the container, not about the API of the
value_type.  So I expect to see the API for that container when I open
the documentation, but when intuitively scrolling up to the list of
member functions it sometimes takes several seconds for me to realize
that I landed on the QVariant page instead. If it were written as
QList I could choose to either open the documentation for
QVariant or for QList.

>
> > And I have to remember if QStringList is the same as as QList,
> > or if it's actually a different container with a different API.
>
> In fact, it is-a QList. What's the problem here with its naming?

The issue is that Qt itself is not consistent with the naming.
QStringList is just an alias for QList, but e.g. QDomNodeList
(https://doc.qt.io/qt-5/qdomnodelist.html) isn't. So unless you've
frequently used the particular type you always have to look it up. If
it were spelled as QList it'd be obvious.

>
> Thanks,
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
>
> ___
> 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

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Giuseppe D'Angelo via Development]

On 4/23/20 5:04 PM, Julius Bullinger wrote:

Another suggestion: Get rid if the aliases; use the fully-qualified
types instead.

I'm always irritated if I open the documentation of QVariantList from
within Qt Creator, and land on the QVariant docu instead. I'm interested
in the features of the container, not the contained type.


This is a documentation bug or a Creator bug. You're supposed to land on
this anchor: https://doc.qt.io/qt-5/qvariant.html#QVariantList-typedef


And I have to remember if QStringList is the same as as QList,
or if it's actually a different container with a different API.


In fact, it is-a QList. What's the problem here with its naming?

Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[André Pönitz]

On Thu, Apr 23, 2020 at 05:04:27PM +0200, Julius Bullinger wrote:
> On 23.04.2020 16:45, Giuseppe D'Angelo via Development wrote:
> > == Naming of functions and types if QList = QVector ==
> > 
> > We have QStringList, QVariantList and friends, which are aliases /
> > subclasses of QList and so on.
> > 
> > Should they become QStringVector, QVariantVector; and the *List names
> > stay, aliases for the *Vector names, mirroring QList and QVector
> > themselves?
> 
> Another suggestion: Get rid if the aliases; use the fully-qualified types
> instead.

In case of QStringList that would be QStringList.

Andre'
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[André Pönitz]

On Thu, Apr 23, 2020 at 12:25:33PM +, Vitaly Fanaskov wrote:
>I think we should completely remove QList in Qt6. It was planned
>before, as far as I remember. The main reason is to be consistent with
>STL wording and do not violate POLA too much.
> 
>I read the entire discussion, and I'd like to say this one more time:
>we don't have to fight the consequences. Better to eliminate a cause.
>There always will be a functionality to deprecate. There always will be
>controversial APIs, that, for example, contain a hard-coded type
>information in the name (e.g. "windowList()" instead of "windows()").
>Why not think about it instead? Today it QVector vs. QList, tomorrow
>something else...
> 
>We can at least shorten release cycle to one year.

One year for a major Qt release and then break API?

How many people have you seen that use Qt as a means to get *their*
problem solved, and how many of them prefered adapting their code to
Qt API changes over working on there own code?

How often do you think we can play this game until people look for
something they consider more stable?

>Provide clang-based tools to (semi-)automatically port users' code
>bases to a new version of Qt.
>
>These tools might either fix a code or at
>least add a comment in potentially problematic places where a user
>should correct the code. A developer who changes API should also
>implement a rule for these tools.

This magic tool comes up over and over again, still no-one "just did it".
Maybe because it's not *that* trivial after all, maybe because doing that
actual porting ends up in real work, which is  much less fun than just
deciding that something needs to be changed, maybe something else.

Really: All this talk "this is bad, should be done differently, and
then it is better" would be much easier to believe if they were accompanied
by patches that implements that change for all of Qt. Or all of KDE.

Andre'
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Julius Bullinger]

On 23.04.2020 16:45, Giuseppe D'Angelo via Development wrote:

== Naming of functions and types if QList = QVector ==

We have QStringList, QVariantList and friends, which are aliases / 
subclasses of QList and so on.


Should they become QStringVector, QVariantVector; and the *List names 
stay, aliases for the *Vector names, mirroring QList and QVector 
themselves?


Another suggestion: Get rid if the aliases; use the fully-qualified 
types instead.


I'm always irritated if I open the documentation of QVariantList from 
within Qt Creator, and land on the QVariant docu instead. I'm interested 
in the features of the container, not the contained type.


And I have to remember if QStringList is the same as as QList, 
or if it's actually a different container with a different API.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Simon Hausmann]

Hi,

You're right, I was mistaken. I tried the virtual method API change locally and 
it works with the aliasing, either way. So it's only a problem if we combined 
it with deprecation and asked our users to move over while they want to 
maintain compatibility with both versions of Qt. Thiago's proposal on the other 
hand avoids the deprecation.



Simon

From: Development  on behalf of Fabian 
Kosmale 
Sent: Thursday, April 23, 2020 11:08
To: development@qt-project.org 
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

Hi,

I don't see the issue with the search with virtual functions. In Qt 5, 
those use QList, so our users will use it there too. In Qt 6, we change it to 
QVector, but as QList is an alias of QVector in Qt 6, the user's code (still 
using QList) will still work just fine.
Am I missing something here?

Fabian

--
Fabian Kosmale
Software Engineer

The Qt Company GmbH
Erich-Thilo-Str. 10
D-12489 Berlin
fabian.kosm...@qt.io
+49 1638686070
http://qt.io

Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
--

Von: Development  im Auftrag von Simon 
Hausmann 
Gesendet: Donnerstag, 23. April 2020 10:52
An: Laszlo Agocs ; Jaroslaw Kobus ; 
Lars Knoll 
Cc: Qt development mailing list 
Betreff: Re: [Development] Proposal: Deprecate QVector in Qt 6

Hi,

If we did the search & replace and use QVector throughout our API, won't that 
make it harder for our users to maintain a code base with 5 and 6? For example 
if we change the signature of virtual functions.

I think we'd do our users a favour by sticking to QList - I'm not concerned 
about the popularity of Qt in online forums but rather about the practical 
difficulties of developing with Qt.


Simon

From: Laszlo Agocs 
Sent: Thursday, April 23, 2020 10:41
To: Jaroslaw Kobus ; Lars Knoll ; Simon 
Hausmann 
Cc: Qt development mailing list 
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

-1 for QList. Why reuse and prioritize a name that has been tainted by plenty 
of past discussions and comes with a lot of past baggage? Any Google etc. 
search will bring up plenty of "QList-bad QVector-good" materials for years to 
come, potentially leading to lots of Qt 5 vs Qt 6 confusion. Also, Qt 5.x is 
not going to disappear overnight.

The current status quo of QList being an alias to QVector in Qt 6, with QVector 
being the primary and recommended name, is pretty good IMHO, it is not clear to 
me why this would need any further changes. An additional search & replace 
(QList->QVector) round in the public headers does not sound like a bad idea at 
all.

Best regards,
Laszlo




From: Development  on behalf of Jaroslaw 
Kobus 
Sent: Thursday, April 23, 2020 10:20 AM
To: Lars Knoll ; Simon Hausmann 
Cc: Qt development mailing list 
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

+1 for QList.

(6) No need to remane QStringList into QStringVector for consistency reasons.

Jarek


From: Development  on behalf of Lars Knoll 

Sent: Thursday, April 23, 2020 9:53 AM
To: Simon Hausmann
Cc: Qt development mailing list
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

I’ve had similar thoughts lately as well. I can see a few more reasons to keep 
QList as the name of the class:

(3) Less ambiguity with QVector(2/3/4)D
(4) QList is the known type and the one promoted in our API so far, so no need 
for people to re-learn Qt
(5) a lot less code churn for us and our users

So I’m in favour of doing this and keeping QList as the name for the class.

Cheers,
Lars

On 23 Apr 2020, at 09:43, Simon Hausmann 
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
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Giuseppe D'Angelo via Development]

On 4/23/20 1:20 PM, Edward Welbourne wrote:

So how much harm does it really cause, to keep both names; and use
whichever feels like the more natural description of the value one is
returning ?


I missing the bigger picture about this thread. What are we trying to 
assess / solve?



== Source compatibility in the presence of QList = QVector (only 
relevant for porting code from Qt 5 to 6)? ==


There are some known breakages [1]. But the example quoted before,

  QList fun();

will still work whether the client code uses QList or QVector to 
store the result. That's why I was asking what that was about.



Similarly,

  QVector fun();

will also allow

  QList l = fun();


Can this cause source incompatibilities? How? How would the proposed 
QVector = QList change things instead?





== API maintenance if QList = QVector: do we mass s/QList/QVector/g in 
our public APIs? ==


I'd be in strong favour of it; it favours consistency and one single 
message.


Please: let's not open the debate about whether it's a good idea to have 
functions that return containers when such containers are not part of 
the object representation (vs: those functions use output iterators, or 
become coroutines, etc., so I can choose the container I want). We have 
those functions around and we need a source compatible solution for them 
in 6.0.


The problem I see with this is the sheer size of the task ahead. I'm not 
sure how much it can be automated. Has anyone tried? Even if some magic 
script fixes everything we may still need manual style touches.


Does it need a C++ parser, or can it be a mass search?

(And even if could build a clang script that does it for Qt itself, what 
about user code which won't compile at all under clang?)


On the positive side, since we're talking about typedefs, this can be 
done incrementally, without any API/ABI compatibility concerns.




If we went the other way around, i.e. QList is the "default" type, like 
proposed: doesn't the task stay fundamentally the same?




== Naming of functions and types if QList = QVector ==

We have QStringList, QVariantList and friends, which are aliases / 
subclasses of QList and so on.


Should they become QStringVector, QVariantVector; and the *List names 
stay, aliases for the *Vector names, mirroring QList and QVector 
themselves?


I'd say yes, but this has another impact on the API maintenance (we 
should change all of our public APIs to use the *Vector types, for 
consistency).


A broader question is: in the long run, do we want start deprecating all 
the *List names, and leave just the *Vector names? If yes, then 
certainly we have to do the replacements.


As proposed in this thread, if we keep QList and make QVector the alias, 
then we would just leave these datatypes unchanged, and there would be 
no need of introducing the *Vector counterparts.



Functions naming: how many public APIs have a "List" suffix, 
specifically returning a QList? (=> QTextCursor::insertList doesn't count.)


First and foremost, we have a problem of coding guidelines, which demand 
simple pluralization of the entity returned, not "List" suffixing:


* QObject::children, not childList
* QObject::dynamicPropertyNames, not dynamicPropertyNameList
* QSslSocket::sslErrors, not sslErrorList
* QRegularExpressionMatch::capturedTexts, not capturedTextList
* QSslConfiguration::supportedEllipticCurves, not 
supportedEllipticCurveVector (yes, this one returns a QVector)


So the first "go to" solution is: rename the functions, so they follow 
the guideline (keep and deprecate the old name).



Second, would it cause confusion for a function called getFooList() to 
return a QVector? Is "list" used as an abstraction of the return type 
(it doesn't return an object, but a sequence of them), or strictly in 
some sort of Hungarian notation to require that the type returned is a 
QList? (And I mean, specifically _spelled_ QList, even if it's an alias 
to QVector).


I don't have a good answer here.


== Terminology, "list" vs "vector"? ==

Debating whether "vector" is a good term for the respective container is 
only useful for mathematicians and linguists -- in other words, all 
aboard the bikeshedding train!


But: *today*, in 2020, in C++, it represents a very specific and 
well-understood thing. Same for "list". They should cause no 
ambiguities. I cannot stress enough that we shouldn't and cannot 
possibly care about the names in other languages!


(Otherwise, "list" in Python is heterogeneous, why isn't QList 
heterogeneous? Don't we care about developers coming from Python? Repeat 
for any other language out there.)


The major problem in this department has to do with caring that 
something is actually a vector (contiguous in memory, etc.) rather than 
just a sequence implemented "somehow" (... as efficiently as possible, 
this is C++ after all).


In this regard, QList is a bad term for representing a generic sequence 
(because "list" already has a meaning in C++).


I'm 

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Simon Hausmann]

Hi,

I think your proposal is fine, too - still counts as something that improves 
the situation for our users and our API. And they'd certainly appreciate one 
deprecation warning less ;-)


Simon

From: Development  on behalf of Thiago 
Macieira 
Sent: Thursday, April 23, 2020 15:52
To: development@qt-project.org 
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

On Thursday, 23 April 2020 02:15:29 PDT Simon Hausmann wrote:
> Proposed:
>
> template  using QVector = QList; // mark deprecated
> template  class QList { $(implementation to be moved); }

Proposal 2:

template  class QList { $(implementation to be moved); }
template  using QVector = QList;

no deprecation.
--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
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

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Thiago Macieira]

On Thursday, 23 April 2020 02:15:29 PDT Simon Hausmann wrote:
> Proposed:
> 
> template  using QVector = QList; // mark deprecated
> template  class QList { $(implementation to be moved); }

Proposal 2:

template  class QList { $(implementation to be moved); }
template  using QVector = QList;

no deprecation.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Thiago Macieira]

On Thursday, 23 April 2020 01:41:54 PDT Laszlo Agocs wrote:
> -1 for QList. Why reuse and prioritize a name that has been tainted by
> plenty of past discussions and comes with a lot of past baggage? Any Google
> etc. search will bring up plenty of "QList-bad QVector-good" materials for
> years to come, potentially leading to lots of Qt 5 vs Qt 6 confusion. Also,
> Qt 5.x is not going to disappear overnight.

The other problem with QList is that std::list is a linked list, whereas 
QList/QVector is an array, like std::vector. I'd like to keep QVector so 
people know what it is. I don't mind keeping both names, actually and I do not 
propose a change from QStringList.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Elvis Stansvik]

Den tors 23 apr. 2020 kl 13:38 skrev André Pönitz :
>
> On Thu, Apr 23, 2020 at 12:48:45PM +0200, Elvis Stansvik wrote:
> > Den tors 23 apr. 2020 kl 11:45 skrev Laszlo Agocs :
> > >
> > > 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/ ?

No, not really, plus looking through the code in each case to make
sure it didn't rely on some QList peculiarity. But it was not much
work.

As I said, I'll accept whatever is decided, but think it would be a
little strange to make this turn in the recommendations at this point.
Everyone who has done this change to QVector will then have to go back
to QList.

Elvis

>
> >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

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Vitaly Fanaskov]

I think we should completely remove QList in Qt6. It was planned before, as far 
as I remember. The main reason is to be consistent with STL wording and do not 
violate POLA too much.

I read the entire discussion, and I'd like to say this one more time: we don't 
have to fight the consequences. Better to eliminate a cause. There always will 
be a functionality to deprecate. There always will be controversial APIs, that, 
for example, contain a hard-coded type information in the name (e.g. 
"windowList()" instead of "windows()"). Why not think about it instead? Today 
it QVector vs. QList, tomorrow something else...

We can at least shorten release cycle to one year.
Provide clang-based tools to (semi-)automatically port users' code bases to a 
new version of Qt. These tools might either fix a code or at least add a 
comment in potentially problematic places where a user should correct the code. 
A developer who changes API should also implement a rule for these tools.
And of course slightly adjust API design guides.


Vitaly


From: Development  on behalf of Simon 
Hausmann 
Sent: Thursday, April 23, 2020 09:43
To: development@qt-project.org 
Subject: [Development] Proposal: Deprecate QVector in Qt 6

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
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[André Somers]

On 23-04-20 12:49, Mitch Curtis wrote:

-Original Message-
From: Development  On Behalf Of
André Somers
Sent: Thursday, 23 April 2020 12:04 PM
To: Jaroslaw Kobus ; 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

QMdiArea::subWindowList(QMdiArea::WindowOrder

order = CreationOrder) const; QList >
QGraphicsItemAnimation::translationList() const;
QList

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


Because

return QVector(set.begin(), set.end());

is obviously easier to write and understand than:

return set.toVector();


Got it.


André


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Morten Sørvig]

> On 23 Apr 2020, at 11:30, Ville Voutilainen  
> wrote:
> 
> On Thu, 23 Apr 2020 at 12:25, Philippe  wrote:
>> 
>> Almost all the time I second your positions, but not this time ;)
>> 
>> QList is historically a cause of ambiguity, and Qt6 is the chance to get rid 
>> of that.
> 
> Indeed. QList causes confusion for the uninitiated that are aware of
> the differences between std::vector and std::list
> (as in Why Do These People Use Lists Everywhere? Why don't they use
> Vectors?). Now we have papered over
> the problem, but the name remains problematic, because QList is not a
> list. In Qt5, QList is sometimes a list,
> sometimes a vector, but in Qt6 it's never a list.

Well at this point and on todays hardware the linked list has become a
very special-purpose container, so it might be reasonable to disambiguate
the other way: “list” is a sequential container but no longer implies “linked”.
It’s not a perfect naming, but we can get away with it :)

QList is our chameleon sequential container whose implementation we can change
to meet new requirements (to a certain degree), now and in the future.

> 
> Switching the QVector implementation over to a type called QList and
> aliasing QVector to that with the intent
> of getting rid of the QVector name seems exactly backwards to me. I
> would think the better approach would
> be to keep dev as it is, and deprecate and eventually remove QList.

QVector, on the other hand, guarantees contiguous storage and also has a place,
like for graphics API as pointed out elsewhere in this thread.

(We should then be careful about adding QList::constData() as public API, since
that will tie down the QList implementation).

- Morten
 


> ___
> 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

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Ville Voutilainen]

On Thu, 23 Apr 2020 at 14:28, André Pönitz  wrote:
>
> On Thu, Apr 23, 2020 at 12:30:32PM +0300, Ville Voutilainen wrote:
> > On Thu, 23 Apr 2020 at 12:25, Philippe  wrote:
> > >
> > > Almost all the time I second your positions, but not this time ;)
> > >
> > > QList is historically a cause of ambiguity, and Qt6 is the chance to get 
> > > rid of that.
> >
> > Indeed. QList causes confusion for the uninitiated that are aware of
> > the differences between std::vector and std::list [...]
>
> And "vector" confuses the uninitiated who expect it to be an element
> of a vector space, to point somewhere, to carry diseases, or to be
> something like a single pointer ("interrupt vector").
>
> I really wonder who thought that "vector" was a good name for a
> container of not necessarily scalar elements that can change its
> dimension.
>
> Maybe someone who was involved with the initial choice of that name
> can share some insight?

Stepanov chose the name; that much we know. Some ruminations, accuracy
unknown. I can't find
any material on it in the newer TC++PL edition I have:
https://stackoverflow.com/questions/581426/why-is-a-c-vector-called-a-vector

QVector is certainly closer to std::vector than QList is to std::list.
Vector isn't a really good name either,
for people recently taught in elementary school math, or for java
programmers coming in.
For C++ programmers, it gives a much better suggestion of what it is
than calling it QList does.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[André Pönitz]

On Thu, Apr 23, 2020 at 12:48:45PM +0200, Elvis Stansvik wrote:
> Den tors 23 apr. 2020 kl 11:45 skrev Laszlo Agocs :
> >
> > 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

Re: [Development] Proposal: Deprecate QVector in Qt 6

[André Pönitz]

On Thu, Apr 23, 2020 at 12:17:38PM +0200, Daniel Engelke wrote:
>> 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.

In other parts of the discussion the point was made that such a renaming
is trivial, and it stands to reason that there's quite a bit more code
using QList in the wild than QVector.

So overall eco-system-effort to convert to QVector is higher than staying
with QList.

Andre'
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[André Pönitz]

On Thu, Apr 23, 2020 at 12:30:32PM +0300, Ville Voutilainen wrote:
> On Thu, 23 Apr 2020 at 12:25, Philippe  wrote:
> >
> > Almost all the time I second your positions, but not this time ;)
> >
> > QList is historically a cause of ambiguity, and Qt6 is the chance to get 
> > rid of that.
> 
> Indeed. QList causes confusion for the uninitiated that are aware of
> the differences between std::vector and std::list [...]

And "vector" confuses the uninitiated who expect it to be an element
of a vector space, to point somewhere, to carry diseases, or to be
something like a single pointer ("interrupt vector").

I really wonder who thought that "vector" was a good name for a 
container of not necessarily scalar elements that can change its
dimension.

Maybe someone who was involved with the initial choice of that name
can share some insight?

Andre'

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[André Pönitz]

On Thu, Apr 23, 2020 at 10:02:04AM +0200, André Pönitz wrote:
> On Thu, Apr 23, 2020 at 07:43:33AM +, Simon Hausmann 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?
> 
> This would avoid *quite* a bit code churn for user code.
> 
> +1

To refine: +1 for staying with QList as the container of choice, and
making QVector an alias for that, but I would not deprecate QVector.

Andre'
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[ekke]

I'm using QList in many cases, per ex:
C++:
  QList myList();

QML:
  ListView { ... model: xxx.myList()

C++
  QVector myList();

getting Error from QML ListView: Unknown method return type: 
QVector


(tested with Qt 5.13.2)

perhaps I misunderstood something or will QML in Qt6 have no problems 
with QVector(QObject*) ?


ekke

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Edward Welbourne]

André Pönitz (23 April 2020 10:52)
> "vector" in this context is a misnomer. It does not "carry" something
> from one place to another,

It is a container, in which values are carried from one piece of code to
another.  The same can, of course, be said of every container.

However, that's all that mathematics was using it to mean, when first it
introduced the term vector.  Then, of course, it refined the meaning to
mean something quite definite and no longer necessarily a carrier for a
bunch of numbers.  Jargon evolves.

> it does not have a direction, it's (generally) not an element of a
> vector space etc.

These are quirks of mathematical jargon; and each discipline gets to
evolve its jargon in its own quirky and eccentric way.  Computer
Scientists started out using arrays of numbers to represent mathematical
vectors (as co-ordinates) but ended up using vector as a fancy word for
an array, then evolving that meaning to whatever it has now become.

> "list" is the better word already.

That I would agree with; although I'm not sure how computer science
jargon feels about it.

> "array" as some ordered arrangment would be in principle ok, to

Indeed.

The etymology and origins of words is, however, much less important than
the state of various folk's source code.  We can have QList and QVector
exist side-by-side without deprecating either, but I think some dislike
the redundancy and want to get rid of at least one of those names for
the type.  However, QList is the name widely used in may of our APIs and
thus, most likely, in many other folk's APIs.  Since we have repeatedly
urged folk to switch away from it, to QVector, it makes little sense to
remove the name QVector.

So how much harm does it really cause, to keep both names; and use
whichever feels like the more natural description of the value one is
returning ?

Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Daniel Engelke]

I wouldn't treat that "List" as type information but rather as "container of 
objects" or simply "multiple objects".
Otherwise all functions would need type information in them aka "isActive()" 
becomes "isActiveBool()".


Dan

 From:   Jaroslaw Kobus  
 To:   André Somers , "development@qt-project.org" 
 
 Sent:   4/23/2020 11:58 AM 
 Subject:   Re: [Development] Proposal: Deprecate QVector in Qt 6 

There are cases, where the name of the function contains the "list", like:

QList QMdiArea::subWindowList(QMdiArea::WindowOrder order = 
CreationOrder) const;
QList > QGraphicsItemAnimation::translationList() const;
QList 
QLowEnergyAdvertisingParameters::whiteList() const;
etc...

So, subWindowList() returning the vector?

Changing QList to QVector may in consequence require even more API changes.

Jarek


From: Development  on behalf of André 
Somers 
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 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 availableSizes(...);


If we have that

    template using QList = QVector;


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 
<mailto:daniel.enge...@basyskom.com>
Sent: Thursday, April 23, 2020 10:52
To: Simon Hausmann <mailto:simon.hausm...@qt.io>
Cc: development@qt-project.org<mailto: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 <mailto:simon.hausm...@qt.io>
To: Dmitriy Purgin <mailto:dpur...@gmail.com>
Cc: "development@qt-project.org"<mailto: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 <mailto:dpur...@gmail.com>
Sent: Thursday, April 23, 2020 9:53
To: Simon Hausmann <mailto:simon.hausm...@qt.io>
Cc: development@qt-project.org<mailto: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 
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,

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Mitch Curtis]

> -Original Message-
> From: Development  On Behalf Of
> André Somers
> Sent: Thursday, 23 April 2020 12:04 PM
> To: Jaroslaw Kobus ; 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
> QMdiArea::subWindowList(QMdiArea::WindowOrder
> > order = CreationOrder) const; QList >
> > QGraphicsItemAnimation::translationList() const;
> > QList
> 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  on behalf of
> > André Somers 
> > 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 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 availableSizes(...);
> >
> >
> > If we have that
> >
> >  template using QList = QVector;
> >
> >
> > 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
> >
> <mailto:daniel.enge...@basyskom.com>
> > Sent: Thursday, April 23, 2020 10:52
> > To: Simon Hausmann
> <mailto:simon.hausm...@qt.io>
> > Cc: development@qt-project.org<mailto: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
> > <mailto:simon.hausm...@qt.io>
> > To: Dmitriy Purgin <mailto:dpur...@gmail.com>
> > Cc: "development@qt-project.org"<mailto: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

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Elvis Stansvik]

Den tors 23 apr. 2020 kl 11:45 skrev Laszlo Agocs :
>
> 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, 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.

Elvis

>
> Best regards,
> Laszlo
>
>
>
> 
> From: Simon Hausmann 
> Sent: Thursday, April 23, 2020 10:52 AM
> To: Laszlo Agocs ; Jaroslaw Kobus ; 
> Lars Knoll 
> Cc: Qt development mailing list 
> Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6
>
> Hi,
>
> If we did the search & replace and use QVector throughout our API, won't that 
> make it harder for our users to maintain a code base with 5 and 6? For 
> example if we change the signature of virtual functions.
>
> I think we'd do our users a favour by sticking to QList - I'm not concerned 
> about the popularity of Qt in online forums but rather about the practical 
> difficulties of developing with Qt.
>
>
> Simon
> 
> From: Laszlo Agocs 
> Sent: Thursday, April 23, 2020 10:41
> To: Jaroslaw Kobus ; Lars Knoll ; 
> Simon Hausmann 
> Cc: Qt development mailing list 
> Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6
>
> -1 for QList. Why reuse and prioritize a name that has been tainted by plenty 
> of past discussions and comes with a lot of past baggage? Any Google etc. 
> search will bring up plenty of "QList-bad QVector-good" materials for years 
> to come, potentially leading to lots of Qt 5 vs Qt 6 confusion. Also, Qt 5.x 
> is not going to disappear overnight.
>
> The current status quo of QList being an alias to QVector in Qt 6, with 
> QVector being the primary and recommended name, is pretty good IMHO, it is 
> not clear to me why this would need any further changes. An additional search 
> & replace (QList->QVector) round in the public headers does not sound like a 
> bad idea at all.
>
> Best regards,
> Laszlo
>
>
>
> ____________
> From: Development  on behalf of Jaroslaw 
> Kobus 
> Sent: Thursday, April 23, 2020 10:20 AM
> To: Lars Knoll ; Simon Hausmann 
> Cc: Qt development mailing list 
> Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6
>
> +1 for QList.
>
> (6) No need to remane QStringList into QStringVector for consistency reasons.
>
> Jarek
>
> 
> From: Development  on behalf of Lars 
> Knoll 
> Sent: Thursday, April 23, 2020 9:53 AM
> To: Simon Hausmann
> Cc: Qt development mailing list
> Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6
>
> I’ve had similar thoughts lately as well. I can see a few more reasons to 
> keep QList as the name of the class:
>
> (3) Less ambiguity with QVector(2/3/4)D
> (4) QList is the known type and the one promoted in our API so far, so no 
> need for people to re-learn Qt
> (5) a lot less code churn for us and our users
>
> So I’m in favour of doing this and keeping QList as the name for the class.
>
> Cheers,
> Lars
>
> On 23 Apr 2020, at 09:43, Simon Hausmann 
> 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 

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Daniel Engelke]

> 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  
 To:   Daniel Engelke  
 Cc:   Simon Hausmann , "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

Re: [Development] Proposal: Deprecate QVector in Qt 6

[André Somers]

Hi,

On 23-04-20 11:58, Jaroslaw Kobus wrote:

There are cases, where the name of the function contains the "list", like:

QList QMdiArea::subWindowList(QMdiArea::WindowOrder order = 
CreationOrder) const;
QList > QGraphicsItemAnimation::translationList() const;
QList 
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().


André




Changing QList to QVector may in consequence require even more API changes.

Jarek


From: Development  on behalf of André Somers 

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 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 availableSizes(...);


If we have that

 template using QList = QVector;


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 
<mailto:daniel.enge...@basyskom.com>
Sent: Thursday, April 23, 2020 10:52
To: Simon Hausmann <mailto:simon.hausm...@qt.io>
Cc: development@qt-project.org<mailto: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 <mailto:simon.hausm...@qt.io>
To: Dmitriy Purgin <mailto:dpur...@gmail.com>
Cc: "development@qt-project.org"<mailto: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 <mailto:dpur...@gmail.com>
Sent: Thursday, April 23, 2020 9:53
To: Simon Hausmann <mailto:simon.hausm...@qt.io>
Cc: development@qt-project.org<mailto: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 
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 Q

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Jaroslaw Kobus]

There are cases, where the name of the function contains the "list", like:

QList QMdiArea::subWindowList(QMdiArea::WindowOrder order = 
CreationOrder) const;
QList > QGraphicsItemAnimation::translationList() const;
QList 
QLowEnergyAdvertisingParameters::whiteList() const;
etc...

So, subWindowList() returning the vector?

Changing QList to QVector may in consequence require even more API changes.

Jarek


From: Development  on behalf of André 
Somers 
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 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 availableSizes(...);


If we have that

template using QList = QVector;


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 
<mailto:daniel.enge...@basyskom.com>
Sent: Thursday, April 23, 2020 10:52
To: Simon Hausmann <mailto:simon.hausm...@qt.io>
Cc: development@qt-project.org<mailto: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 <mailto:simon.hausm...@qt.io>
To: Dmitriy Purgin <mailto:dpur...@gmail.com>
Cc: "development@qt-project.org"<mailto: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 <mailto:dpur...@gmail.com>
Sent: Thursday, April 23, 2020 9:53
To: Simon Hausmann <mailto:simon.hausm...@qt.io>
Cc: development@qt-project.org<mailto: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 
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/develo

Re: [Development] Proposal: Deprecate QVector in Qt 6

[André Pönitz]

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

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Giuseppe D'Angelo via Development]

On 4/23/20 10:55 AM, Simon Hausmann wrote:

So take for example this function in QIconEngine:

virtual QList 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.


Why do you say "we require"? What kind of user code would break?

Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[André Pönitz]

On Thu, Apr 23, 2020 at 10:06:07AM +0200, Albert Astals Cid via Development 
wrote:
> El dijous, 23 d’abril de 2020, a les 9:43:33 CEST, Simon Hausmann va escriure:
> > 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?
> 
> As taught in Computer Science/Engineering courses:
>  * QList is not a list
>  * QVector is a vector

"vector" in this context is a misnomer. It does not "carry" something
from one place to another, it does not have a direction, it's (generally)
not an element of a vector space etc.

"list" is the better word already. To lists can be appended etc, operations
that do not apply to elemens of vector spaces. "array" as some ordered
arrangment would be in principle ok, to, but see below.

> Compating to std:: types:
>  * QList is not comparable to a std::list
>  * QVector is comparable to a std::vector
> 
> Personally i think it makes sense to keep the QVector name.

The problem is that this triggers tons of practically needless
renamings in tons of user code without actual gain.

And as QVector is longer than QList, this in turn will trigger 
reformatting due to exceeded line lenght limits. Etc.

Effectively only pain, no gain.

Andre'
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[André Pönitz]

On Thu, Apr 23, 2020 at 07:43:33AM +, Simon Hausmann 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?

This would avoid *quite* a bit code churn for user code.

+1

Andre'

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Ville Voutilainen]

On Thu, 23 Apr 2020 at 12:25, Philippe  wrote:
>
> Almost all the time I second your positions, but not this time ;)
>
> QList is historically a cause of ambiguity, and Qt6 is the chance to get rid 
> of that.

Indeed. QList causes confusion for the uninitiated that are aware of
the differences between std::vector and std::list
(as in Why Do These People Use Lists Everywhere? Why don't they use
Vectors?). Now we have papered over
the problem, but the name remains problematic, because QList is not a
list. In Qt5, QList is sometimes a list,
sometimes a vector, but in Qt6 it's never a list.

Switching the QVector implementation over to a type called QList and
aliasing QVector to that with the intent
of getting rid of the QVector name seems exactly backwards to me. I
would think the better approach would
be to keep dev as it is, and deprecate and eventually remove QList.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Albert Astals Cid via Development]

El dijous, 23 d’abril de 2020, a les 10:27:15 CEST, Simon Hausmann va 
escriure:
> 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.

People would still need to have different code, i.e. they would need to use 
QVector in Qt5 (as QList is "bad") and QList in Qt6 (as QVector would be 
deprecated).

Cheers,
  Albert

> 
> 
> Simon
> 
> From: Dmitriy Purgin 
> Sent: Thursday, April 23, 2020 9:53
> To: Simon Hausmann 
> Cc: 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
> 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


-- 
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [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 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 availableSizes(...);


If we have that

    template using QList = QVector;


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 
*Sent:* Thursday, April 23, 2020 10:52
*To:* Simon Hausmann 
*Cc:* 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 
*To: *Dmitriy Purgin 
*Cc: *"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 
*Sent:* Thursday, April 23, 2020 9:53
*To:* Simon Hausmann 
*Cc:* 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
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
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

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Laszlo Agocs]

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.

Best regards,
Laszlo




From: Simon Hausmann 
Sent: Thursday, April 23, 2020 10:52 AM
To: Laszlo Agocs ; Jaroslaw Kobus ; 
Lars Knoll 
Cc: Qt development mailing list 
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

Hi,

If we did the search & replace and use QVector throughout our API, won't that 
make it harder for our users to maintain a code base with 5 and 6? For example 
if we change the signature of virtual functions.

I think we'd do our users a favour by sticking to QList - I'm not concerned 
about the popularity of Qt in online forums but rather about the practical 
difficulties of developing with Qt.


Simon

From: Laszlo Agocs 
Sent: Thursday, April 23, 2020 10:41
To: Jaroslaw Kobus ; Lars Knoll ; Simon 
Hausmann 
Cc: Qt development mailing list 
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

-1 for QList. Why reuse and prioritize a name that has been tainted by plenty 
of past discussions and comes with a lot of past baggage? Any Google etc. 
search will bring up plenty of "QList-bad QVector-good" materials for years to 
come, potentially leading to lots of Qt 5 vs Qt 6 confusion. Also, Qt 5.x is 
not going to disappear overnight.

The current status quo of QList being an alias to QVector in Qt 6, with QVector 
being the primary and recommended name, is pretty good IMHO, it is not clear to 
me why this would need any further changes. An additional search & replace 
(QList->QVector) round in the public headers does not sound like a bad idea at 
all.

Best regards,
Laszlo




From: Development  on behalf of Jaroslaw 
Kobus 
Sent: Thursday, April 23, 2020 10:20 AM
To: Lars Knoll ; Simon Hausmann 
Cc: Qt development mailing list 
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

+1 for QList.

(6) No need to remane QStringList into QStringVector for consistency reasons.

Jarek


From: Development  on behalf of Lars Knoll 

Sent: Thursday, April 23, 2020 9:53 AM
To: Simon Hausmann
Cc: Qt development mailing list
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

I’ve had similar thoughts lately as well. I can see a few more reasons to keep 
QList as the name of the class:

(3) Less ambiguity with QVector(2/3/4)D
(4) QList is the known type and the one promoted in our API so far, so no need 
for people to re-learn Qt
(5) a lot less code churn for us and our users

So I’m in favour of doing this and keeping QList as the name for the class.

Cheers,
Lars

On 23 Apr 2020, at 09:43, Simon Hausmann 
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
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Simon Hausmann]

Hi,

Ah yes, I'm suggesting to keep the implementation in Qt 6, so:

Qt 6 QList == Qt 6 QVector and deprecate Qt 6 Vector.


Or differently put:

Currently:

template  class QVector { $(implementation to be moved) }
template  using QList = QVector;

Proposed:

template  using QVector = QList; // mark deprecated
template  class QList { $(implementation to be moved); }

I hope that clarifies the intent.

Simon

From: Development  on behalf of Albert 
Astals Cid via Development 
Sent: Thursday, April 23, 2020 10:52
To: development@qt-project.org 
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

El dijous, 23 d’abril de 2020, a les 10:23:21 CEST, Simon Hausmann va
escriure:
> Hi,
>
> Yes, apologies, QList is an alias for QVector. I propose to switch that
> around.

But keeping which implementation?

I.e. it's not clear if you are suggesting to make
   Qt6 QList == Qt5 QVector and deprecate Qt6 QVector
or
   Qt6 QList == Qt5 QList and deprecate Qt6 QVector

Cheers,
  Albert

>
>
> Simon
>
> 
> From: Development  on behalf of Albert
> Astals Cid via Development  Sent: Thursday,
> April 23, 2020 10:16
> To: development@qt-project.org 
> Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6
>
> El dijous, 23 d’abril de 2020, a les 9:43:33 CEST, Simon Hausmann va
escriure:
> > Hi,
> >
> > In dev we've had QVector being an alias for QList for a while now.
>
> It's the other way around, isn't it?
>
> corelib/tools/qcontainerfwd.h:
> template using QList = QVector;
>
> Cheers,
>   Albert
>
> --
> Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - The Qt, C++ and OpenGL Experts
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development


--
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

___
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

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Fabian Kosmale]

Hi,

I don't see the issue with the search with virtual functions. In Qt 5, 
those use QList, so our users will use it there too. In Qt 6, we change it to 
QVector, but as QList is an alias of QVector in Qt 6, the user's code (still 
using QList) will still work just fine.
Am I missing something here?

Fabian

--
Fabian Kosmale
Software Engineer

The Qt Company GmbH
Erich-Thilo-Str. 10
D-12489 Berlin
fabian.kosm...@qt.io
+49 1638686070
http://qt.io

Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
--

Von: Development  im Auftrag von Simon 
Hausmann 
Gesendet: Donnerstag, 23. April 2020 10:52
An: Laszlo Agocs ; Jaroslaw Kobus ; 
Lars Knoll 
Cc: Qt development mailing list 
Betreff: Re: [Development] Proposal: Deprecate QVector in Qt 6

Hi,

If we did the search & replace and use QVector throughout our API, won't that 
make it harder for our users to maintain a code base with 5 and 6? For example 
if we change the signature of virtual functions.

I think we'd do our users a favour by sticking to QList - I'm not concerned 
about the popularity of Qt in online forums but rather about the practical 
difficulties of developing with Qt.


Simon

From: Laszlo Agocs 
Sent: Thursday, April 23, 2020 10:41
To: Jaroslaw Kobus ; Lars Knoll ; Simon 
Hausmann 
Cc: Qt development mailing list 
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

-1 for QList. Why reuse and prioritize a name that has been tainted by plenty 
of past discussions and comes with a lot of past baggage? Any Google etc. 
search will bring up plenty of "QList-bad QVector-good" materials for years to 
come, potentially leading to lots of Qt 5 vs Qt 6 confusion. Also, Qt 5.x is 
not going to disappear overnight.

The current status quo of QList being an alias to QVector in Qt 6, with QVector 
being the primary and recommended name, is pretty good IMHO, it is not clear to 
me why this would need any further changes. An additional search & replace 
(QList->QVector) round in the public headers does not sound like a bad idea at 
all.

Best regards,
Laszlo




From: Development  on behalf of Jaroslaw 
Kobus 
Sent: Thursday, April 23, 2020 10:20 AM
To: Lars Knoll ; Simon Hausmann 
Cc: Qt development mailing list 
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

+1 for QList.

(6) No need to remane QStringList into QStringVector for consistency reasons.

Jarek


From: Development  on behalf of Lars Knoll 

Sent: Thursday, April 23, 2020 9:53 AM
To: Simon Hausmann
Cc: Qt development mailing list
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

I’ve had similar thoughts lately as well. I can see a few more reasons to keep 
QList as the name of the class:

(3) Less ambiguity with QVector(2/3/4)D
(4) QList is the known type and the one promoted in our API so far, so no need 
for people to re-learn Qt
(5) a lot less code churn for us and our users

So I’m in favour of doing this and keeping QList as the name for the class.

Cheers,
Lars

On 23 Apr 2020, at 09:43, Simon Hausmann 
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
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Philippe]

Almost all the time I second your positions, but not this time ;)

QList is historically a cause of ambiguity, and Qt6 is the chance to get rid of 
that.

Philippe

On Thu, 23 Apr 2020 07:53:04 +
Lars Knoll  wrote:

I’ve had similar thoughts lately as well. I can see a few more reasons to keep 
QList as the name of the class: 
> 
> 
> (3) Less ambiguity with QVector(2/3/4)D
> (4) QList is the known type and the one promoted in our API so far, so no 
> need for people to re-learn Qt
> (5) a lot less code churn for us and our users
> 
> 
> So I’m in favour of doing this and keeping QList as the name for the class.
> 
> 
> Cheers,
> Lars
> 
>> On 23 Apr 2020, at 09:43, Simon Hausmann  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
>> https://lists.qt-project.org/listinfo/development





___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Shawn Rutledge]

> On 2020 Apr 23, at 10:27, Simon Hausmann  wrote:
> 
> 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.

Won’t the “using” declaration keep working for the foreseeable future, so that 
they don’t have to change legacy code?

I guess the trouble is when writing new code that they want to use with both Qt 
versions, they would need to use QList, at least for now.  But that’s a 
short-term problem until Qt 5 is obsolete.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Simon Hausmann]

Hi,

So take for example this function in QIconEngine:

virtual QList 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)

Simon

From: Daniel Engelke 
Sent: Thursday, April 23, 2020 10:52
To: Simon Hausmann 
Cc: 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 
To: Dmitriy Purgin 
Cc: "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 
Sent: Thursday, April 23, 2020 9:53
To: Simon Hausmann 
Cc: 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 
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
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Albert Astals Cid via Development]

El dijous, 23 d’abril de 2020, a les 10:23:21 CEST, Simon Hausmann va 
escriure:
> Hi,
> 
> Yes, apologies, QList is an alias for QVector. I propose to switch that
> around.

But keeping which implementation?

I.e. it's not clear if you are suggesting to make 
   Qt6 QList == Qt5 QVector and deprecate Qt6 QVector
or
   Qt6 QList == Qt5 QList and deprecate Qt6 QVector

Cheers,
  Albert

> 
> 
> Simon
> 
> 
> From: Development  on behalf of Albert
> Astals Cid via Development  Sent: Thursday,
> April 23, 2020 10:16
> To: development@qt-project.org 
> Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6
> 
> El dijous, 23 d’abril de 2020, a les 9:43:33 CEST, Simon Hausmann va 
escriure:
> > Hi,
> > 
> > In dev we've had QVector being an alias for QList for a while now.
> 
> It's the other way around, isn't it?
> 
> corelib/tools/qcontainerfwd.h:
> template using QList = QVector;
> 
> Cheers,
>   Albert
> 
> --
> Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - The Qt, C++ and OpenGL Experts
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development


-- 
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Simon Hausmann]

Hi,

If we did the search & replace and use QVector throughout our API, won't that 
make it harder for our users to maintain a code base with 5 and 6? For example 
if we change the signature of virtual functions.

I think we'd do our users a favour by sticking to QList - I'm not concerned 
about the popularity of Qt in online forums but rather about the practical 
difficulties of developing with Qt.


Simon

From: Laszlo Agocs 
Sent: Thursday, April 23, 2020 10:41
To: Jaroslaw Kobus ; Lars Knoll ; Simon 
Hausmann 
Cc: Qt development mailing list 
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

-1 for QList. Why reuse and prioritize a name that has been tainted by plenty 
of past discussions and comes with a lot of past baggage? Any Google etc. 
search will bring up plenty of "QList-bad QVector-good" materials for years to 
come, potentially leading to lots of Qt 5 vs Qt 6 confusion. Also, Qt 5.x is 
not going to disappear overnight.

The current status quo of QList being an alias to QVector in Qt 6, with QVector 
being the primary and recommended name, is pretty good IMHO, it is not clear to 
me why this would need any further changes. An additional search & replace 
(QList->QVector) round in the public headers does not sound like a bad idea at 
all.

Best regards,
Laszlo




From: Development  on behalf of Jaroslaw 
Kobus 
Sent: Thursday, April 23, 2020 10:20 AM
To: Lars Knoll ; Simon Hausmann 
Cc: Qt development mailing list 
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

+1 for QList.

(6) No need to remane QStringList into QStringVector for consistency reasons.

Jarek


From: Development  on behalf of Lars Knoll 

Sent: Thursday, April 23, 2020 9:53 AM
To: Simon Hausmann
Cc: Qt development mailing list
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

I’ve had similar thoughts lately as well. I can see a few more reasons to keep 
QList as the name of the class:

(3) Less ambiguity with QVector(2/3/4)D
(4) QList is the known type and the one promoted in our API so far, so no need 
for people to re-learn Qt
(5) a lot less code churn for us and our users

So I’m in favour of doing this and keeping QList as the name for the class.

Cheers,
Lars

On 23 Apr 2020, at 09:43, Simon Hausmann 
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
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Daniel Engelke]

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  
 To:   Dmitriy Purgin  
 Cc:   "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 
 Sent: Thursday, April 23, 2020 9:53
 To: Simon Hausmann 
 Cc: 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  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
 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

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Laszlo Agocs]

-1 for QList. Why reuse and prioritize a name that has been tainted by plenty 
of past discussions and comes with a lot of past baggage? Any Google etc. 
search will bring up plenty of "QList-bad QVector-good" materials for years to 
come, potentially leading to lots of Qt 5 vs Qt 6 confusion. Also, Qt 5.x is 
not going to disappear overnight.

The current status quo of QList being an alias to QVector in Qt 6, with QVector 
being the primary and recommended name, is pretty good IMHO, it is not clear to 
me why this would need any further changes. An additional search & replace 
(QList->QVector) round in the public headers does not sound like a bad idea at 
all.

Best regards,
Laszlo




From: Development  on behalf of Jaroslaw 
Kobus 
Sent: Thursday, April 23, 2020 10:20 AM
To: Lars Knoll ; Simon Hausmann 
Cc: Qt development mailing list 
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

+1 for QList.

(6) No need to remane QStringList into QStringVector for consistency reasons.

Jarek


From: Development  on behalf of Lars Knoll 

Sent: Thursday, April 23, 2020 9:53 AM
To: Simon Hausmann
Cc: Qt development mailing list
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

I’ve had similar thoughts lately as well. I can see a few more reasons to keep 
QList as the name of the class:

(3) Less ambiguity with QVector(2/3/4)D
(4) QList is the known type and the one promoted in our API so far, so no need 
for people to re-learn Qt
(5) a lot less code churn for us and our users

So I’m in favour of doing this and keeping QList as the name for the class.

Cheers,
Lars

On 23 Apr 2020, at 09:43, Simon Hausmann 
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
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Simon Hausmann]

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 
Sent: Thursday, April 23, 2020 9:53
To: Simon Hausmann 
Cc: 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 
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
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Simon Hausmann]

Hi,

Yes, the "proximity" of QVector to std::vector is on argument in favour of it. 
However I'm not certain that that's worth giving up on the goal of making it 
easy to maintain a code base between 5 and 6 with a consistent API in Qt. At 
the end of the day we serve our users 

That said, what do you think we should do about this situation?


Simon

From: Development  on behalf of Albert 
Astals Cid via Development 
Sent: Thursday, April 23, 2020 10:06
To: development@qt-project.org 
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

El dijous, 23 d’abril de 2020, a les 9:43:33 CEST, Simon Hausmann va escriure:
> 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?

As taught in Computer Science/Engineering courses:
 * QList is not a list
 * QVector is a vector

Compating to std:: types:
 * QList is not comparable to a std::list
 * QVector is comparable to a std::vector

Personally i think it makes sense to keep the QVector name.

Cheers,
  Albert

>
>
> Simon


--
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

___
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

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Simon Hausmann]

Hi,

Yes, apologies, QList is an alias for QVector. I propose to switch that around.


Simon


From: Development  on behalf of Albert 
Astals Cid via Development 
Sent: Thursday, April 23, 2020 10:16
To: development@qt-project.org 
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

El dijous, 23 d’abril de 2020, a les 9:43:33 CEST, Simon Hausmann va escriure:
> Hi,
>
> In dev we've had QVector being an alias for QList for a while now.

It's the other way around, isn't it?

corelib/tools/qcontainerfwd.h:
template using QList = QVector;

Cheers,
  Albert

--
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

___
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

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Jaroslaw Kobus]

+1 for QList.

(6) No need to remane QStringList into QStringVector for consistency reasons.

Jarek


From: Development  on behalf of Lars Knoll 

Sent: Thursday, April 23, 2020 9:53 AM
To: Simon Hausmann
Cc: Qt development mailing list
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

I’ve had similar thoughts lately as well. I can see a few more reasons to keep 
QList as the name of the class:

(3) Less ambiguity with QVector(2/3/4)D
(4) QList is the known type and the one promoted in our API so far, so no need 
for people to re-learn Qt
(5) a lot less code churn for us and our users

So I’m in favour of doing this and keeping QList as the name for the class.

Cheers,
Lars

On 23 Apr 2020, at 09:43, Simon Hausmann 
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
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Albert Astals Cid via Development]

El dijous, 23 d’abril de 2020, a les 9:43:33 CEST, Simon Hausmann va escriure:
> Hi,
> 
> In dev we've had QVector being an alias for QList for a while now. 

It's the other way around, isn't it?

corelib/tools/qcontainerfwd.h:
template using QList = QVector;

Cheers,
  Albert

-- 
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Albert Astals Cid via Development]

El dijous, 23 d’abril de 2020, a les 9:43:33 CEST, Simon Hausmann va escriure:
> 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?

As taught in Computer Science/Engineering courses:
 * QList is not a list
 * QVector is a vector

Compating to std:: types:
 * QList is not comparable to a std::list
 * QVector is comparable to a std::vector

Personally i think it makes sense to keep the QVector name.

Cheers,
  Albert

> 
> 
> Simon


-- 
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Dmitriy Purgin]

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  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
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Lars Knoll]

I’ve had similar thoughts lately as well. I can see a few more reasons to keep 
QList as the name of the class:

(3) Less ambiguity with QVector(2/3/4)D
(4) QList is the known type and the one promoted in our API so far, so no need 
for people to re-learn Qt
(5) a lot less code churn for us and our users

So I’m in favour of doing this and keeping QList as the name for the class.

Cheers,
Lars

On 23 Apr 2020, at 09:43, Simon Hausmann 
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
https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Proposal: Deprecate QVector in Qt 6

[Simon Hausmann]

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
https://lists.qt-project.org/listinfo/development