[Development] How qAsConst and qExchange lead to qNN

[A. Pönitz]

On Mon, Nov 07, 2022 at 08:15:58PM +0000, Marc Mutz via Development wrote:
> Hi all,
> 
> SCNR taking the proffered bait:
> 
> On 07.11.22 18:51, Edward Welbourne wrote:
> > For Qt to remain relevant in the rapidly-evolving C++ landscape, it
> > needs to change; but one of its strong selling-points has long been its
> > conservatism in API and ABI, that lets working code keep working.
> 
> I've not been around for the Qt 1 → Qt 2 port, but I did participate in 
> all of the Qt 2 → Qt 3, Qt 3 → Qt 4, Qt 4 → Qt 5 and Qt 5 → Qt 6 
> transitions. Speaking with my Qt user hat on, I'm terribly sorry to 
> inform y'all that Qt has largely _failed_ to keep working code working. 
> Sure, a trivial QWidgets program from the mid-90s may still compile and 
> work in Qt 6, but as soon as said program touches Qt container classes, 
> it's game over.

Staying wiht unmodified Qt 4 containers would very likely just have
worked in Qt 6 and not have caused any problems for users upgrading
their applications during the last 15 years.
 
> Both Boost and C++ itself have a much better track record of keeping 
> working code working, let alone any random C library. And this is 
> actually a fair comparison, because we're comparing apples (STL 
> containers) to apples (Qt containers).

No. Goals of STL and Qt containers are /quite/ different.

Qt offers convenience and ease of use while still being "good enough"
at performance for normal use. STL can give better performance in some
cases, but needs more handholding, more alertness from the user, and
it's easier to get things completely wrong, also performance-wise.

This is absolutely not "apples vs apples", rather (tr("Nicht alles, was
hinkt, ist ein Vergleich, aber:")) "cars vs motorcycles": Sure, they have
a lot in common, but none is uniformly "better" than the other.

> Let's not kid ourselves thinking Qt is any special here. It isn't. We 
> mustn't just look at one major release cycle. Qt loses projects at every 
> new major release, because changes to non-core-competency parts of the 
> API make porting unnecessarily complicated, so that unmaintained or 
> understaffed projects[1] cannot muster the strength to be ported.

I consider this an absurd line of reasoning coming from /you/.

You, /personally/ /you/, have been the driving force behind a
significant amount of /from my perspective/ unnecessary and absolutely
unwelcomed changes like the removal of Q(5)List that I predicted to be
and now apparently _is_ hampering "understaffed projects" (which in my
book covers pretty much /every/ open source projects and quite a few
commercial ones) to move from Qt 5 to Qt 6.

This "loss of projects" is not the consequence of any natural law or
divine intervention. Even "understaffed projects" can typically "muster
the strength" to do _necessary_ adaptations to _critical_ problems.
However, it is completely no surprise _to me_ that they do not want to
jump through any hoop that is effectively only busy-work, not solving
any real problem.

> My goal with qNN is to make porting away _simple_. All that's required 
> is to s/qNN::/std::/ and be done. No deprecation, no sanity bot, not 
> even the need for local code knowledge; just simple global textual 
> replacement. And no regressions, if you first switch to C++NN, and only 
> then do the replacement. We can even retain the qNN symbols until Qt 
> requires C++(NN+3), because the qNN headers will be nothing but a long 
> list of using std::foo; at that time.
> 
> It's not really acceptable that such trivial ports should be subjected 
> to all the same (or, apparently since it's done in bulk, more 
> restrictive) requirements than for deprecation of core-competency APIs. 
> The more so as I must have missed the outcry of developers when we inflicted

_To me_ it is not really acceptable that (parts of) qtbase are treated
as playground for experiments. [And _I_ _do_ think that e.g.  calling
"string literal qualifications du jour" that barely last for a year "an
experiment" is fair].

In my world, deprecations ("trivial" or not) _in a library_ should only
happen as a consequence of an unexpected _and_ fundamental _and_ otherwise
unfixable flaws in the API, causing _real_ (not "imagined") harm for "a
lot" of users. This should never be used wantonly, and definitely not
pre-planned.

> To hold users, a project must maintain _long-term_ API stability, not 
> rewrite the container classes for every major release.

... grrrr ... 

> So, sorry, but as a user of Qt I'd really like to use those stable STL 
> classes, if only your volatile APIs let me. I'd rather I had done that 
> _one_ port between Qt 1 and 2 than all those ports in Qt 1-6.

Again, /you/, /personally/ /you/, have been /actively/ involved and
promoted and/or done part of these /breaking/ changes. I haven't checked
explicitly, but my best guess is that Qt 4.0 (2005(!)) would
container-wise be "good enough" for my current needs. And it's not that
STL has't changed since then...

[And just to make sure: With "current needs" I herewith take the liberty
to not speak just for my personal one or two hobbyist projects using Qt,
but also for my day time job.]

> Well, as they say, if 20 years ago was the best time to do the switch, 
> then the next-best time is today[2].
> 
> Anyway; to all those who disagree when I say Qt should concentrate on 
> its core competencies and stop meddling with container classes, shared 
> pointers, etc, I say this: which of the two universes above would you 
> rather have lived in these past 30 years? A or B? Be truthful!

I prefer a universe where people work towards a common goal. If there
are fundamentally incompatible goals (as apparently the case here), I
tend to prefer the goals that the vast majority of "neighbours" in this
context prefer -- or I leave the context.

I was happy enough (and still am...) using Qt. The most distracting
issue on the pure technical side for me is this attempt to "de-Qt" Qt.
 
> Because, you see, whenever we phase out some Qt NIH API,

[And since we are at it: It would ease my life (but possibly hamper the
life of my cardiologist) if you wouldn't call it "Qt NIH API". This is
an open insult to people who actively designed these APIs _with
different goals_ than the STL. I personally think it's completely fine
if you don't agree with these different goals, but then please accept
that these goals exist, too]

> we beam a small part of your (and our!) code from Universe A into the
> Universe B. I _really_ can't understand why anyone would complain.

I am typically completely fine with people holding different opinions than I,
related to code or otherwise. I occasionally even find it interesting to
discuss certain issues beyond the point of "I accept that you have a
different opinion", most notably if that opinion can be expressed as the
logical consequence of certain axioms - and that's even independent of
whether these axiom are or are not relevant in /my/ world.

I do, however, complain when something is needlessly causing busy-work
for me that doesn't fix any of my problems. And that is definitely the
case here.

Andre'

PS:

> Must be a case of recency bias or something like that...
> 
> Speaking of the devil, from my pov, qAsConst isn't "small enough" to
> survive. Fighting off patches that try to make the deleted rvalue
> overload "do something" is _also_ maintenance work, even if it doesn't
> result in a code change.
> 
> Finally, I'll bet my behind (pardon my French) that at some point in
> the not-too-distant future someone will appear on Gerrit with a patch
> to change Q_FOREACH to use C++20 ranged-for-with-initializer:
>    #define Q_FOREACH(decl, expr) \ for (const auto _q_foreach_c =
>    expr; decl : _q_foreach_c)
> And I'd probably approve it, because then that thing can actually just
> be replaced with the expansion everywhere, and then, finally, be
> deleted.

[I can make 100% correct predictions about changes I intent to push, too.
What's the point?]