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

[Mutz, Marc]

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

Thanks,
Marc