[Development] The future of smart pointers in Qt API

André Pönitz apoenitz at t-online.de
Tue Feb 4 22:28:19 CET 2020


On Tue, Feb 04, 2020 at 07:42:22AM +0100, Giuseppe D'Angelo wrote:
> Il 03/02/20 23:55, André Pönitz ha scritto:
> > On Mon, Feb 03, 2020 at 10:25:21PM +0100, Giuseppe D'Angelo wrote:
> > > Il 03/02/20 20:38, André Pönitz ha scritto:
> > > > Directly affected are for instance functions operating on full containers in
> > > > 
> > > >     https://doc.qt.io/qt-5/qtalgorithms-obsolete.html
> > > 
> > > Just to set the record straight, the main reason why qAlgorithm(begin, end)
> > > as well as qAlgorithm(container) have been deprecated altogether, rather
> > > than simply have their implementation replaced with std::algorithm() calls,
> > > was the fact it would've been source incompatible.
> > 
> > I think I've never needed qAlgorithm(begin, end), but used quite a bit of
> > qAlgorithm(container).
> > 
> > > For instance: qSort internally uses calls to qSwap and qLess.
> > 
> > So what?  It worked.  Now it doesn't anymore.
> 
> So changing qAlgorithm(container) implementation to call
> std::algorithm(container.begin(), container.end()) would have been a source
> incompatible change.

Which might have been in the acceptable range, i.e. on par with the other
incompatible changes within a major release. I don't think there are overly
many sensible pieces of code that implement std::swap() observably differently
than qSwap() for the same type.

> (Side note: throughout the entire Qt 5 lifetime qAlgorithm(container) still
> 100% works -- it's deprecated, not removed.)

['deprecated' means 'removed' in my universe... Which also might explain allergic
reactions towards 'deprecation without pre-existing alternatives' etc.]

> In other words, in the Qt4->5 time, the choice was between one of these:
> 
> A) Keep QtAlgorithms as-is between Qt 4 and Qt 5, leave them fully
> supported.
> 
> B) Keep QtAlgorithms API as fully supported, but change the implementation
> under the hood to use std::algorithms.
> 
> C) Deprecate QtAlgorithms API, leave them as-is for Qt 4 compatibility. Tell
> the users that they have Qt 5.x entire lifetime to migrate away.
> 
> D) Something else: e.g. add the convenience wrappers back in some other
> namespace (after the port to std::algorithms, so with different semantics)
> etc.; no one has proposed or done so far.

B. Or A.

> B) is a "hidden" source incompatible change (code would still compile but
> break at runtime).

*shrug*

It would not *generally* "break at runtime", it would "break at runtime _for some
very weird setups_". This happens practically, intentionally or not, with each Qt
minor, even patch releases, and is completely acceptable for a major releases.

> So we went for C).

> Was all of this done because "I don't need qAlgorithms' convenience so no
> one needs it"? Absolutely not!
> 
> Should we had gone for B) instead? I say no, QUIP-6 says no,

QUIPs are unreleated: QUIPs didn't exist at the time, and 4->5 was a major
release, which QUIP-6 is not about.

> are feel to say yes. (Side note: this *will* fuel arguments against using Qt
> facilities, namely, "Qt regularly breaks them".)

(I was quite happy with the level of breakage between 4 and 5, and I'd be
more than happy if 5 to 6 would have been about the same (non-)pain.)

> No: it would break existing code without the user changing their code at
> all.
> 
> Qt 4: qSort(foo) (uses qLess)
> Qt 5: qSort(foo) (uses std::less)

Formally "yes", but as already stated ...
 
> Users don't change their code; code compiles just as before; behavior and
> thus semantics of the call change, possibly breaking at runtime.

... that happens *all the time* even with minor releases, some intended,
some simply new bugs. Accepting this, but insisting that people might 
sensibly have different qLess and std::less implementations *and* rely
on that is an interesting stance to take.`

> > There is not upstream 'sort(Container)' that this has possibly diverged from.
> 
> Oh wai, in C++20 there is :-P

Indeed. Diverging from something that will only be invented in eight years
time is incredibly naughty ;-P

> More seriously: is this arguing for having qSort(container) still around
> with the Qt 4 implementation?

s/4/5/ ? Yes. And until it's in released std::, there too.

> > That 'porting away' basically consists of creating a layer of convenience
> > ex-Qt functions on top of Qt. Same implementation initially, deviating
> > now on a per-project base.
> 
> I, for one, would welcome centralization of these efforts. Anyone else?

I guess that ship has sailed.  "Centralizing" would currently mean to bring
it back to Qt. By now people have either forked qalgorithm or they do not
care about the issue. In both scenarios, a revived Qt implementation would
not be very attractive.

Andre'



More information about the Development mailing list