[Development] The future of smart pointers in Qt API

[André Pönitz]

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.

> An user overloading or specializing them would have had their algorithms
> broken by the mere replacement towards std::sort (which instead uses an
> ADL-found swap() + std::swap, and std::less).

And most user code breaks by a mere replacement of 0 by 1.

What kind of argument is that?

"Break existing code, since other code might potentially break
when uses replace some function by something else"?

> So, for the record, if you want to point the finger against the
> deprecation/removal of these algorithms, please point it against the
> decision of making the Qt 4 algorithms _diverge_ from upstream, then
> noticing that Qt cannot or shouldn't catch up with the significant
> improvements happening upstream, then realizing that a direct port isn't
> doable because of the diversion. I have already said that having different
> behavior from from upstream is a terrible idea in this very thread, and the
> algorithms example is an excellent one.

There is not upstream 'sort(Container)' that this has possibly diverged from.

> Now, we may disagree on the extent of the incompatibility -- in the end, who
> would override qSwap, specialize qLess, and so on? Can't we just bite the
> bullet and break those rare usages rather than forcing everyone to port
> away?

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.
 
> As the one who did the porting work, then I get the privilege to say: no, we
> can't; this is a gratuitous and very hidden source-incompatible change, and
> the promise of Qt 4->5 was to keep them at a minimum. (And, I don't like
> them.) So, keep using the deprecated qAlgorithms if you want, throughout the
> entire Qt 5.x lifetime, with the same Qt 4.x semantics; they still work just
> like before. _Port_ to the std:: equivalents at your earliest convenience
> (no, you cannot do a mere s/qAlgorithm/std::algorithm/ in the general case;
> it's a full port).

You don't need what I need, so you kill it, and I am forced to re-create
it on my own time. Overall, this approach de-values Qt.

And now we are back to the fallacy thing "I don't need it, noone else does",
which was the actual point. No matter what the actual topic is, I consider
it a fundamental necessity of any sensible discussion that both sides are
allowed to use the same kind of arguments. So if "I don't need it, noone else
does" is considered a valid argument for one side, the other side has to
be allowed to use it as well. Alternatively, neither side should use it
(which actually would be my prefered setup, but that seems out of question)

Andre'