08.06.2019, 19:16, "Giuseppe D'Angelo via Development" <development@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.dang...@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@qt-project.org > https://lists.qt-project.org/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
