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

[Kevin Kofler]

Giuseppe D'Angelo via Development wrote:
> There are some practical problems with this:
> 
> 1) It creates technological debt into QtCore, where we have to keep this
> stuff around forever (and working and supported on *all* platforms, and
> compatible with the latest compilers, etc.).

You call that "technological debt", I call it "backwards compatibility".

> 2) It creates technological debt all around Qt implementation, where the
> "worse" choice (for some factor of worse) may be made, and that's
> something a C++ library should never, ever do.

If it is the developer's (library user's) choice, it is probably the better 
choice for the developer's needs. Just because something is part of the C++ 
standard (in the STL section) does not automatically make it the "better" 
choice. If I prefer the Qt way, there is probably a good reason to.

> 3) It still creates a massive teaching problem (for instance, the
> perennial "which one should I use? Qt containers or STL containers? Qt
> atomics or STL atomics? Qt smart pointers or STL smart pointers? Qt
> mutexes or STL mutexes?" and so on). Unlike what it has been claimed
> elsewhere, people now arrive to Qt from all sorts of backgrounds, so
> these questions DESERVE accurate answers.

Of course always the Qt one!

That is exactly one of my points: Qt should not require its users to use any 
STL classes. What should be taught to developers is consistent use of QtCore 
classes. If you want to learn Qt, learn Qt. If you want to learn the STL, 
learn the STL. If you want to mix&match whatever serves you better, you can, 
but then you need to learn both. But this is advanced guru-level knowledge 
that beginners should not be bothered with.

Just as you would not expect all C++ developers to learn assembly because it 
allows writing more efficient code, you should not expect all Qt developers 
to learn the STL either, even if the STL happens to be more efficient for 
some use cases. Convenience and consistency have their value. Otherwise, 
languages such as Python would not exist at all.

I also consider it a mistake to port internal Qt code from QtCore to STL 
containers as has been done in several places. Qt should "eat its own 
dogfood" here.

> 4) The most important one: the moment some of this stuff is exposed as
> public API, the users are no longer free to choose. We have
> QSharedPointer, QHash, (well, QList), and more stuff and similar in Qt
> APIs. That's Qt making the decision for the user, so saying "they can
> always go and use the STL" is false.

Well, yes, where containers are use in Qt APIs, of course they should be Qt 
containers!

You can choose the container type for your own containers in your own code 
as you wish, though.

> I know that solving the type exchange at the API level is a much, much
> bigger fish to fry. I'm just saying that it IS a compatibility problem
> that forces the user's hand.

And that is expected, I do not see the issue with it.

        Kevin Kofler