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

[Konstantin Tokarev]

08.06.2019, 19:16, "Giuseppe D'Angelo via Development" <development at qt-project.org>:
> 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?". 

I once written code which relied on overload of qSwap performance-wise.
At the same time, I couldn't force GCC to use my std::swap overload in std::sort
(IIRC it worked fine with clang/libc++ only)


> 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
>
> ,
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Regards,
Konstantin