08.06.2019, 21:33, "André Pönitz" <apoen...@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@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
