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

[Mutz, Marc]

On 2019-05-29 20:21, Vitaly Fanaskov wrote:
> After all, STL updates approximately once in three years. So, we can
> easily follow all changes and update Qt API accordingly. It’s
> probably worth reusing something (e.g. time suffixes from chrono), but
> carefully.

Well, yes. If Qt _had_ a track-record of following up on STL API 
changes, fine. I'd actually welcome a QHash that had a node_handle 
interface I could use already without having to wait for C++17.

But as it stands, Qt has a track-record of a) _partially_ reimplementing 
std functionality, b) adding _one_ killer feature (QVector: realloc, 
QMutex: futex, ...) and then c) _not_ continue maintenance. The result 
just sits there, bitrots, while the std classes get more and more 
features. The Qt containers don't even, as of now, have all the C++98 
API (range ctor, map doesn't even have range-erase(!)). And you can't 
hold move-only types in them. Surely, you're as addicted to unique_ptr 
as everyone else (if not, you haven't used it, yet). But to hold a 
collection of them, you must turn to the STL.

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.

And this is precisely why Qt should be rebased on later C++ standards: 
To increase interop with the ever-growing std library and "proper" C++ 
libraries using it, and to avoid having to maintain a copy of libstdc++ 
going forward. Because I have provided, from 2012-2017, about 1/4 of 
that maintenance work, and I can attest with confidence that this is a 
job for at least an FTE, probably more. And I don't see where this 
manpower should come from.

Thanks,
Marc