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] Clang-based refactoring to Qt 6 (Proposal: Deprecate QVector in Qt 6)

[Sérgio Martins via Development]

On 2020-04-23 14:55, Thiago Macieira wrote:

On Thursday, 23 April 2020 05:25:33 PDT Vitaly Fanaskov wrote:
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 was discussed in a QtCS two or three years ago. There are two huge
problems with that:

1) Clang cannot compile all Qt-using codebases. Therefore, its tooling 
cannot

work in all cases either.


This is less of a problem nowadays, where clang can even be a drop-in 
replacement for MSVC.

Embedded requires hacked mkspecs though (QNX for example).


2) No one has volunteered to write such conversion scripts.

And a minor (3) is that automatic conversions seldom look nice and will
require manual retouching anyway.


Specially when talking about QList -> QVector, as QVector doesn't 
guarantee the stability of references due to reallocation.


Tooling could still flag the places where you're taking references so 
you can do a manual verification though.



Regards,
--
Sérgio Martins | sergio.mart...@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

[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

[Development] Qt Visual Studio Tools 2.5.0 released

[Miguel Costa]

A development release of version 2.5 of the Qt VS Tools is now available.
(Changelog: 
https://code.qt.io/cgit/qt-labs/vstools.git/tree/Changelog?id=0048dbab02ca6ee81dd3b27ff1525e02ce756ac7
 )

Installation packages for v2.5.0 can be downloaded from:

https://download.qt.io/development_releases/vsaddin/2.5.0/
   (for the moment, only available for Visual Studio 2017 and 2019)

If no high-priority issues are found, we will upload this version to the VS 
Marketplace. In the meantime, please feel free to download and install it, and 
let us know what you find; bug reports and suggestions are welcome at:

https://bugreports.qt.io/projects/QTVSADDINBUG

Thank you.


--Miguel Costa
Software Engineer

The Qt Company GmbH
Erich-Thilo-Straße 10
D-12489 Berlin
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

___
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] Clang-based refactoring to Qt 6 (Proposal: Deprecate QVector in Qt 6)

[Vitaly Fanaskov]

1) Clang cannot compile all Qt-using codebases. Therefore, its tooling cannot
work in all cases either.
That's true, but on the other hand, covering at least a half of code bases 
would be a huge progress. I don't have representative statistics, but I guess 
that the real percentage will be larger.

2) No one has volunteered to write such conversion scripts
Well, it could be a problem if there were no more or less commercially 
successful companies behind the Qt. There is a business value in such a tool. 
Of course providing porting as a service might bring more money, but it cannot 
be fully automated anyway.

And a minor (3) is that automatic conversions seldom look nice and will
require manual retouching anyway.
Yes, sure. As I said before, it should be OK to automatically convert only the 
most straightforward cases and mark others. Even marking is already a very 
helpful thing.


Vitaly


From: Development  on behalf of Thiago 
Macieira 
Sent: Thursday, April 23, 2020 15:55
To: development@qt-project.org 
Subject: [Development] Clang-based refactoring to Qt 6 (Proposal: Deprecate 
QVector in Qt 6)

On Thursday, 23 April 2020 05:25:33 PDT Vitaly Fanaskov wrote:
> 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 was discussed in a QtCS two or three years ago. There are two huge
problems with that:

1) Clang cannot compile all Qt-using codebases. Therefore, its tooling cannot
work in all cases either.

2) No one has volunteered to write such conversion scripts.

And a minor (3) is that automatic conversions seldom look nice and will
require manual retouching anyway.
--
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

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

[Development] Clang-based refactoring to Qt 6 (Proposal: Deprecate QVector in Qt 6)

[Thiago Macieira]

On Thursday, 23 April 2020 05:25:33 PDT Vitaly Fanaskov wrote:
> 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 was discussed in a QtCS two or three years ago. There are two huge 
problems with that:

1) Clang cannot compile all Qt-using codebases. Therefore, its tooling cannot 
work in all cases either.

2) No one has volunteered to write such conversion scripts.

And a minor (3) is that automatic conversions seldom look nice and will 
require manual retouching anyway.
-- 
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 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] [Announce] Qt Creator 4.12 released

[Henry Skoglund]

On 2020-04-23 11:48, List for announcements regarding Qt releases and 
development wrote:

We are happy to announce the release of Qt Creator 4.12!

https://www.qt.io/blog/qt-creator-4.12-released

Thank you! I like the new Restart feature, i.e. when you switch Theme, 
say from Flat Light to Flat Dark, Qt Creator now suggests to restart by 
itself (instead of saying "will take effect after restart" and you have 
to do it yourself).


___
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

[Development] Coin production update 1.4

[Toni Saario]

Hi everyone,

Coin version 1.4 has gone thorough testing process and a Coin production update 
is scheduled for tomorrow 24.4.2020 at 1pm CEST. In the update the Coin 
instance is moved to another host. This causes all modules to be rebuilt as 
storage is not transferred in the process. The rebuilding causes longer 
integration times for short time after the update, expect most of this to 
happen over the weekend.

The changes included in the 1.4 are available at Coin change log page after 
update has landed. If any issues arise with the Coin please report issues to 
Coin project on Jira.


-Toni Saario, Coin maintainer
___
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

[Development] HEADS-UP: Branching from '5.15' to '5.15.0' done

[Jani Heikkinen]

Hi all,

Branching from '5.15' to '5.15.0' is now done. So from now on all changes 
targeted to Qt 5.15.0 release must to be done in '5.15.0' and '5.15' is for Qt 
5.15.1.
As usual no any nice-to-haves in '5.15.0' anymore. Target is to publish Qt 
5.15.0 RC at the end of April and so on we really need to minimize changes in 
'5.15.0' from now on. So only release blockers are taken in. 

Staging in '5.15.0' is restricted to release team only and we will stage 
changes in automatically so no need to ping us.

And target is that after RC we don't take any fixes in. It means all known 
blockers (blocker list here: https://bugreports.qt.io/issues/?filter=21925 ) 
must be fixed before RC. If some new blockers found when testing RC we need to 
publish additional RC but hoping we don't need to do that...

br,
Jani Heikkinen
Release Manager

> -Original Message-
> From: Development  On Behalf Of
> Jani Heikkinen
> Sent: torstai 16. huhtikuuta 2020 11.02
> To: development@qt-project.org
> Cc: releas...@qt-project.org
> Subject: [Development] HEADS-UP: Branching from '5.15' to '5.15.0' started
> 
> Hi,
> 
> We have soft branched '5.15.0' from '5.15' now. So from now on all new
> changes targeted to Qt 5.15.0 release should be done in '5.15.0'. Final
> downmerge from '5.15' to '5.15.0' will happen Wed 22th April so there is
> enough time to finalize ongoing changes in '5.15'.
> 
> Target is to release Qt 5.15.0 RC at the end of April so please make sure all
> release blockers are visible in Qt 5.15.0 release blocker list
> (https://bugreports.qt.io/issues/?filter=21925) and all blockers will be fixed
> immediately.
> 
> Initial changes files for Qt 5.15.0 will be created soon; please finalize 
> those as
> soon as possible
> 
> br,
> Jani Heikkinen
> Release Manager
> ___
> 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 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 

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 

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

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

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 

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.

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 

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


___
Development mailing list

[Development] [Announce] Qt Creator 4.12 released

[List for announcements regarding Qt releases and development]

We are happy to announce the release of Qt Creator 4.12!

https://www.qt.io/blog/qt-creator-4.12-released

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Erich-Thilo-Straße 10
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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