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

[Konstantin Tokarev]

08.06.2019, 21:33, "André Pönitz" <apoenitz at t-online.de>:
> On Sat, Jun 08, 2019 at 06:14:36PM +0200, Giuseppe D'Angelo via Development wrote:
>>  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.).
>
> I see that pattern, too. But now, instead putting the break between 3) and 4),
> the whole thing is killed, and everybody downstream has to do 1)-3) again,
> or put up with what the standard offers.
>
> And could prevent overextension by -x'ing the respective change on gerrit.
> So *that* sounds fixable.
>
>>  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.)
>
> The last one is the most reasonable.
>
>>  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.
>
> Proactively preventing a possible future API break by removing things
> immediately is a questionable approach. Taken to the extreme this means
> each and every bit of Qt should be removed as otherwise it might break API
> at some time.
>
>>  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.
>
> *shrug*
>
> And what if I, as a user, would not care?
>
> What about https://valdyas.org/fading/hacking/happy-porting/
>
>    "[...] none, not a single one of all of the reasons you want to deprecate
>    Q_FOREACH is a reason I care even a little bit about. It’s going to
>    be deprecated? Well, that’s a decision, and a dumb one. It doesn’t
>    work on std containers, QVarLengthArray or C arrays? I don’t use
>    it on those. It adds 100 bytes of text size? Piffle. It makes it hard
>    to reason about the loop for you? I don’t care.
>
>    What I do care is the 1559 places where we use Q_FOREACH in Krita.
>    Porting this will take weeks. [...]"
>
> ?

This kind of porting could be automated with clang-based tool, if anyone cared to
make it. This tool could automatically use qAsConst/std::as_const for non-const
lvalues and add temporary variable for non-const rvalues, without user even
knowing what the hell are lvalues and rvalues and other things Marc writes about.


>
>>  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"?
>
> We won't find consensus here.
>
> QT_I_DO_NO_CARE_ABOUT_ABI_BUT_I_CARE_ABOUT_SOURCE_COMPATIBILITY would be a
> good starting point for all my personal use cases. For other it isn't.
>
> What I see happening is that projects simply stick for longer with older
> versions of Qt the more effort the upgrade is. These are practically
> cold forks, fragmenting the ecosystem. Needlessly, if you ask me.
>
> Andre'
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Regards,
Konstantin