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

[Giuseppe D'Angelo]

On 05/06/2019 23:01, André Pönitz wrote:
> As a matter of fact, some of the previous deprecations, e.g. the removal
> of qalgorithm, triggered re-implementing the deprecated functionality
> downstream, effectively shifting the burden of doing (or, rather,
> *keeping*) them once centrally to all users who need it decentrally.

The huge impact that these deprecations have is also due to another 
reason: the approach of systematically diverging from "upstream".

Qt really really fails at not over-extending (in the name of 
convenience, or compatibility, or whatever). Especially for such 
low-level facilities there is a hidden, slow trend at:

1) taking something "upstream" lacks, or is available only in very 
recent versions, or is not as widespread as it should be, or similar 
(limiting ourselves to "upstream" == Standard Library, that used to be 
the case with QtAlgorithms and -no-stl; one could say the same with 
QSharedPointer/QWeakPointer, and so on.)

2) reimplementing it so that our users have it (yay!)

3) giving it easier APIs (yay!)

4) *extending* it in incompatible ways with upstream 
(QWeakPointer(QObject*); QSharedPointer in QVariants; etc.).


Then, it comes a moment when "upstream" stuff has more and more 
advantages -- more speed (algorithms), more flexibility (e.g. mutex 
classes and utilities; shared_ptr<T[]>; etc.), more static analysis 
tooling, and so on, than the equivalent classes offered in Qt.

In other words, the advantages of keeping the Qt equivalents start to be 
(seriously) questioned. We're therefore left with the question of what 
to do with these equivalents.

* We could play the catch-up game, but that requires a development 
investment that is simply not there any more, and is even questionable 
(is it the job of people developing Qt to rewrite algorithms widely 
available elsewhere?).

* We could move the Qt equivalents into a "support library", maybe with 
deprecation warnings, maybe without. I'm not sure of the traction of 
this idea these days, but IIRC having "Qt4Support" was frowned upon when 
Qt 5 was being shaped. (Thus QtAlgorithms was left in QtCore, deprecated.)

* We could just deprecate and tell people to migrate away. That's kind 
of the whole point of this thread, and comes with all the annoyances, 
and people reimplementing them downstream because they still want the 
convenience of a qSort(vector) over std::sort(vector.begin(), vector.end()).

* We could keep things where they are, supported, thus offering the 
easier APIs; but simply reimplement them on top of the "upstream" 
equivalents. (Ignore the possible ABI break.)

Here's where the "extension" bites us: if the Qt equivalent offered 
something that upstream is not offering, and we can't reimplement it, 
then what do we do? Dropping support for it would be, at best, an API 
break; and at worst, a _silent_ behavioural change.


This is exactly the case of what happened with QtAlgorithms. I believe 
the culprit back then was the usage of qSwap / qLess or so into the 
algorithms themselves (don't remember all the details; also this was pre 
C++11, and using detection idioms and SFINAE to work around this 
would've been another major fun -- file it under "development investment").

Long story short, making qSort() call std::sort() might not have kept 
the behaviour contract with the user.

Is that break acceptable? Is it not acceptable? It's debatable, as 
usual; but please don't give me the "who in their minds overloads qSwap 
/ qLess / qFoobar anyhow?". When it comes to fundamental stuff in QtCore 
(containers, algorithms, etc.) I'd like to stay on the conservative 
side; and therefore the decision, in the end, was to deprecate 
QtAlgorithms rather than porting them over stdlib ones.

(If you want, it's a corollary of Hyrum's law. The lower you are a 
software stack, the bigger is your number of users => and Hyrum follows...)


Now, if everyone is unhappy and reimplements QtAlgorithms in their own 
projects, I guess that was the wrong decision? Are we committing it all 
over again when Qt 6 comes and we drop many deprecated APIs? Should we 
think about a Qt5Support module, without API/ABI promises, where to dump 
things without deprecation warnings, just a big bold writing on top "no 
guarantees are given for these things"?


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/20190608/f7cb3970/attachment.bin>