[Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Elvis Stansvik]

Den ons 5 juni 2019 kl 12:59 skrev Mutz, Marc via Development
<development at qt-project.org>:
>
> On 2019-06-03 14:27, Bernhard Lindner wrote:
> >> > > > So, yes, this is borne out of frustration with the lack of maintenance
> >> > > > of QtCore plumbing. I don't see that changing and I acknowledge and
> >> > > > understand that the focus of development has shifted towards QML.
> >> > > Suppose you implement all planned actions for Qt6 (see your original e-mail). Are
> >> > > the
> >> > > remaining components (those that are neither deprecated nor removed) of Qt6 well
> >> > > maintained and are there enough staff available not only to maintain them
> >> > > indefinitely
> >> > > but to actively develop them further?
> >> >
> >> > No answer to my question above?
> >>
> >> Who do you expect an answer to this question from?
> >>
> >> The Qt Company? The Qt community? Marc? Thiago?
> >
> > Whoever believes being able to make a realistic assessment.
> >
> > If there is no such person/group in this list, which can do an
> > estimate how much of Qt is
> > affordable, an important aspect of the Qt 6 discussion can not
> > actually be discussed. How
> > can Marc think about removing (or significantly changing) Qt due to
> > ressource limits or
> > new strategic goals if the limits or goals are unknown?
> >
> > Actions out of frustration are never a good idea. And pushing into a
> > (technical) direction
> > that does not solve the underlying (strategical) problem is futile.
>
> I think it's pretty clear that some parts of Qt thrive (e.g. QString)
> and others, incl. the other containers, lag behind. I can't speak for
> TQC, but I do wonder where all the manpower that is now proposed to make
> Qt containers wrappers around std ones, etc, suddenly should come from
> when it was lacking for the last decade.
>
> An example: The Qt docs made fun of how hard it is to iterate backwards
> using STL containers, as opposed to Java-Style ones
> (https://doc.qt.io/archives/qt-4.8/containers.html#java-style-iterators),
> yet, in roughly the same time it took to write that nonsense, a
> developer could have implemented rbegin()/rend() on Qt containers.
> Likewise, since I added rvalue-push_back to QVector a few years ago,
> no-one stepped up to implement this for everyone's favourite container,
> QList. Nor any other Qt container. Not _one_. This, and many other such
> instances, show me that the Qt containers are considered good enough,
> and there's absolutely no interest in bringing them forward into the
> 21st century. If you believe otherwise, prove it.
>
> But containers are one of the cornerstones of programming, and there's a
> reason that we now have emplacement, node_handle, move-only payload type
> support, splicing, etc. etc. Where are those functions on Qt containers?
> For that matter, why is there no Qt version of std::set? I removed at
> lest three implementation of an OrderedSet that used a QMap<V,bool> to
> imitate a std::set from QtCore alone. Where is that container, please?
> Where is QDeque? Where is QForwardList? Where is the 25-year-old
> optimisation that implements Container<T*> in terms of Container<void*>.
> IIRC, even the original STL had that. Where is the const_iterator
> overload of QVector::erase()? In particular with CoW, only detaching if
> you actually found the object should be something that everyone yearns
> for. People complain that std::mutex is slower than QMutex, but they
> don't complain that erase(const_iterator) is missing.
>
> You don't need a crystal ball to see that there's not even enough
> manpower to bring in the "recent" (well, C++98 is 20 years ago) changes
> from the STL, let alone innovate.
>
> If users use a QMap<T,bool> because they have an aversion against
> std::set, for one reason or another, where _is_ the Qt answer? Since
> 4.0, the answer has been "you're on your own". So, the honest answer
> would be that Qt doesn't care about it's container classes any more, and
> recommends every user to move over to the STL versions where-ever they
> can.
>
> But some people still live in a bubble universe where, contrary to
> historic proof, the Qt containers will be made great again, any-time
> soon now. Just wait for it...

I think you said it near the beginning of your mail:

> [...] This, and many other such instances, show me that the Qt containers are considered good enough [...]

I guess that is the case. At least I haven't craved for any of the
features you list in the 15 or so year's I've developed with Qt. The
plumbing has been good enough both for my personal and professional
projects, and I guess that may be the case for many others as well.

Don't get me wrong, I absolutely think there are cases where the lack
of these container features is a sore point, just wanted to say that I
haven't spent a lot of time thinking about it, and the same may be
true for many others as well.

Elvis

>
> Thanks,
> Marc
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development