On 20/05/2020 13.15, Lars Knoll wrote:
On 20 May 2020, at 17:34, Matthew Woehlke wrote:
On 20/05/2020 09.11, Lars Knoll wrote:
Here’s what we will do:
* QList and QVector are aliases for each other
* We make QList the main type, and QVector an alias to it
* We keep both names, QList and
On 20 May 2020, at 17:34, Matthew Woehlke
mailto:mwoehlke.fl...@gmail.com>> wrote:
On 20/05/2020 09.11, Lars Knoll wrote:
Here’s what we will do:
* QList and QVector are aliases for each other
* We make QList the main type, and QVector an alias to it
* We keep both names, QList and QVector. None
On 20/05/2020 09.11, Lars Knoll wrote:
Here’s what we will do:
* QList and QVector are aliases for each other
* We make QList the main type, and QVector an alias to it
* We keep both names, QList and QVector. None of them is deprecated
While I don't object to this as such, can someone remind
On Wed, May 20, 2020 at 3:12 PM Lars Knoll wrote:
>
> It’s been a while since Simon started this thread. I’m sure some people will
> disagree, no matter what we do. But I’d like to conclude it, so we have one
> solution for Qt 6.
>
> My focus is on reducing migration pain for our users and
It’s been a while since Simon started this thread. I’m sure some people will
disagree, no matter what we do. But I’d like to conclude it, so we have one
solution for Qt 6.
My focus is on reducing migration pain for our users and ourselves (we’ve got
more than enough things to finish…), as well
On 4/23/20 11:10 PM, Vitaly Fanaskov wrote:
Moving to one year release approach doesn't equal to make Qt less
stable.
> Ville:
>>> Of course it does, if we now allow API breaks every year.
On Fri, 24 Apr 2020 at 13:38, Edward Welbourne wrote:
>> Not necessarily: if we *allow* API
On Mon, 27 Apr 2020 at 10:10, Alberto Mardegan
wrote:
>
> On 23/04/20 14:57, Ville Voutilainen wrote:
> > QVector is certainly closer to std::vector than QList is to std::list.
> > Vector isn't a really good name either,
> > for people recently taught in elementary school math, or for java
> >
On 23/04/20 14:57, Ville Voutilainen wrote:
> QVector is certainly closer to std::vector than QList is to std::list.
> Vector isn't a really good name either,
> for people recently taught in elementary school math, or for java
> programmers coming in.
> For C++ programmers, it gives a much better
I suppose, there are plans to keep the old QList implementation under the
different name (QArrayList/Q5List).
Can we also add the same typedef in Qt5 (using Q5List = QList)? This will
simplify the transition for the people who want to build against Qt5 and Qt6 at
the same time.
Ivan
:14 PM
> > From: "Giuseppe D'Angelo"
> > To: "Jason H"
> > Cc: development@qt-project.org
> > Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6
> >
> > On 4/24/20 9:03 PM, Jason H wrote:
> > >> In fact, it is-a QList. Wh
> Sent: Friday, April 24, 2020 at 4:14 PM
> From: "Giuseppe D'Angelo"
> To: "Jason H"
> Cc: development@qt-project.org
> Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6
>
> On 4/24/20 9:03 PM, Jason H wrote:
> >> In fact, it i
On 4/24/20 9:03 PM, Jason H wrote:
In fact, it is-a QList. What's the problem here with its naming?
Because I can't QSringList{"me", "you"}.join() with a QList.
I didn't say that it's a typedef for QList, but is-a -- it
inherits, precisely to provide that kind of convenience.
Thinking
> Sent: Thursday, April 23, 2020 at 12:05 PM
> From: "Giuseppe D'Angelo via Development"
> To: development@qt-project.org
> Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6
>
> On 4/23/20 5:04 PM, Julius Bullinger wrote:
> > Another sugge
On Thursday, 23 April 2020 08:04:27 PDT Julius Bullinger wrote:
> And I have to remember if QStringList is the same as as QList,
> or if it's actually a different container with a different API.
In Qt 5 it is a different type with extra API. In Qt 6, those extra methods
should move to an extra
> But if the majority thinks that the class name is burned
Majority of whom? I am fairly certain most Qt developers either didn't know
about QList controversy or didn't care about it enough to consider it in
their code.
The only people who care are ones in this mailing list most likely. Imo.
On
On 4/24/20 18:10, Giuseppe D'Angelo via Development wrote:
On 4/24/20 8:57 AM, Joerg Bornemann wrote:
Alternatively, proposal 3 (aka "do almost nothing"):
template class QVector { implementation }
template using QList = QVector;
No deprecation of QVector.
No replacement of QList
On 4/24/20 8:57 AM, Joerg Bornemann wrote:
Alternatively, proposal 3 (aka "do almost nothing"):
template class QVector { implementation }
template using QList = QVector;
No deprecation of QVector.
No replacement of QList with QVector in our API.
Rationale: QList is our default
On Fri, 24 Apr 2020 at 13:58, Edward Welbourne wrote:
>
> Giuseppe D'Angelo (24 April 2020 10:19) asked
> >>> Which "one year release approach" are we talking about here?
>
> On 4/24/20 12:36 PM, Edward Welbourne wrote:
> >> That would be Vitaly's proposal to have major releases yearly.
>
>
On Fri, 24 Apr 2020 at 13:38, Edward Welbourne wrote:
>
> On 4/23/20 11:10 PM, Vitaly Fanaskov wrote:
> >> Moving to one year release approach doesn't equal to make Qt less stable.
>
> Ville:
> > Of course it does, if we now allow API breaks every year.
>
> Not necessarily: if we *allow* API
On 24/04/2020 07.51, André Pönitz wrote:
So what is left is the question about what is in the name. That question was
interestingly enough not present at the begin of the crusade, it only came up
after it turned out that blind replacement of QList by QVector wasn't *that*
trivial and actually
+1 for proposal 3.
I don’t see any reason to repeat all the arguments against the original
proposal, I cannot agree more.
Ivan
> 24 апр. 2020 г., в 08:57, Joerg Bornemann написал(а):
>
> On 4/23/20 15:52, Thiago Macieira wrote:
>
>>> Proposed:
>>>
>>> template using QVector = QList;
On Fri, Apr 24, 2020 at 09:33:49AM +0200, Christian Ehrlicher wrote:
> Am 24.04.2020 um 09:22 schrieb Lars Knoll:
> > > e "vector is a silly name from a mathematical standpoint" argument is
> > > valid,
> > > but vector is an established term in C++ world. Sorry, that ship has
> > > sailed.
> >
Giuseppe D'Angelo (24 April 2020 10:19) asked
>>> Which "one year release approach" are we talking about here?
On 4/24/20 12:36 PM, Edward Welbourne wrote:
>> That would be Vitaly's proposal to have major releases yearly.
Giuseppe D'Angelo (April 24, 2020 12:38)
> I must be missing something:
Giuseppe said:
First and foremost, we have a problem of coding guidelines, which
demand simple pluralization of the entity returned, not "List"
suffixing:
and conforming with that would fix the *List naming problem, so by all
means let's do that during the lifetime of Qt6,
On 4/24/20 12:36 PM, Edward Welbourne wrote:
Giuseppe D'Angelo (24 April 2020 10:19) asked
Which "one year release approach" are we talking about here?
That would be Vitaly's proposal to have major releases yearly.
I must be missing something: how would that help, regarding the problem
at
On 4/23/20 11:10 PM, Vitaly Fanaskov wrote:
>> Moving to one year release approach doesn't equal to make Qt less stable.
Ville:
> Of course it does, if we now allow API breaks every year.
Not necessarily: if we *allow* API breaks every year *but* are
restrained in our use of them - so that, in
On 4/23/20 11:10 PM, Vitaly Fanaskov wrote:
How often do you think we can play this game until people look for
something they consider more stable?
Moving to one year release approach doesn't equal to make Qt less stable.
Which "one year release approach" are we talking about here?
Am 24.04.2020 um 09:22 schrieb Lars Knoll:
e "vector is a silly name from a mathematical standpoint" argument is valid,
but vector is an established term in C++ world. Sorry, that ship has sailed.
I am also in favor of proposal 2 or 3. I think deprecating either QList or
QVector without any
> On 24 Apr 2020, at 09:11, Oliver Wolff wrote:
>
> Hi
>
> On 24.04.2020 08:57, Joerg Bornemann wrote:
>> On 4/23/20 15:52, Thiago Macieira wrote:
Proposed:
template using QVector = QList; // mark deprecated
template class QList { $(implementation to be moved);
Hi
On 24.04.2020 08:57, Joerg Bornemann wrote:
On 4/23/20 15:52, Thiago Macieira wrote:
Proposed:
template using QVector = QList; // mark deprecated
template class QList { $(implementation to be
moved); }
Proposal 2:
template class QList { $(implementation to be moved);
On 4/23/20 15:52, Thiago Macieira wrote:
Proposed:
template using QVector = QList; // mark deprecated
template class QList { $(implementation to be moved); }
Proposal 2:
template class QList { $(implementation to be moved); }
template using QVector = QList;
no
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.
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. Th
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
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
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
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,
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
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
>
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
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 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
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,
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
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
, 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 { $(im
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
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
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
pment@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
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
> 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.
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
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
> >
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
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.
>
>
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
>
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
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
slaw 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::Win
> -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-
t;
> 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,
>
>
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 str
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 cha
aniel Engelke
<mailto:daniel.enge...@basyskom.com>
Sent: Thursday, April 23, 2020 10:52
To: Simon Hausmann <mailto:simon.hausm...@qt.io>
Cc: development@qt-project.org<mailto:development@qt-project.org>
<mailto:development@qt-project.org>
Subject: Re: [Development] Proposal: Deprecate QVect
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
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
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
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
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
.
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,
>
&
*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
,
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 QVe
-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
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
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:
Ive had similar thoughts lately as well. I can see a few more reasons to keep
> 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
, 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
velopment@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.
>
>
: 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
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 cent
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: Simo
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
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
] 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
: [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
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
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
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
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
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
91 matches
Mail list logo
