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

[Giuseppe D'Angelo]

On 09/06/2019 00:00, Kevin Kofler wrote:
> There is one option missing:
> 
> * We could just keep the Qt equivalent as is, without adding the features
>    of the STL equivalent if there is no manpower to port them to the Qt
>    equivalent. Developers using the Qt version are happy with the Qt version
>    as is, and those that are not can always go and use the STL. There is no
>    point in deprecating or splitting out those classes, they should just
>    remain in QtCore where they belong.

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

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.

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.

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.

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.

My 2 c,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4329 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190610/372bdaf4/attachment.bin>