[Development] QtCS 2024 session on deprecations: what did we actually agree on?

[Marc Mutz]

On 14.01.25 14:50, Volker Hilsheimer wrote:
> None of this implies that “Qt 7 will be source compatible with Qt 6”, or
>   results in the automatism that Qt5Compat (or QtCharts, DataViz3D)
> continue to be included and maintained in Qt 7. Some things will stay,
> some won’t. We now have more ways to express (and allow a reviewer to
> confirm) which tradeoff we think is the right one, based on what we know
>   right now.

Forgive me, but that sounds quite a bit like the status quo.

AFAICT, this whole issue came up because of two things:

First, that projects insist on compiling with deprecation warnings 
enabled, but OTOH don't want to port away from deprecated APIs.

The answer here is: if you don't want to port away from deprecated APIs, 
then don't enable deprecation warnings. Let us do our job deprecating 
APIs that we think new code should no longer use and as compensation, we 
promise that removal of deprecated API is the exception, and no longer 
the rule.

Second, that we lose users with every major release. I don't know why, 
but I guess porting (either away from removed Qt APIs or away from 
now-unsupported tool-chains) is the reason for the vast majority of such 
"stuck in the past" projects.

For both of these angles, the solution, from a user pov, is to _not_ 
remove APIs. If we can't commit, as a project, to a _substantial_ 
reduction of known-to-be-removed APIs, then why do we make a distinction 
at all? Users are not helped if 5% of APIs now survive that would have 
been slashed before. Users are helped if 95% of APIs stay, though.

Can we clearly commit (from the project (and TQtC)) that the default is 
to _not_ remove. Including, but not limited to, the case where there is 
no 98/99% replacement. I'd go so far as to require to demonstrate an 
actual benefit for the _user_ from the removal.

Some random examples that came up in water cooler talks:

As removal candidate, Q5ThreadPool::cancel() comes to mind. That API was 
impossible to use correctly, and we quickly provided a working 
replacement (tryCancel()). Today, QSqlQuery's copy ctor came up as a 
removal candidate. Apparently, it, too, cannot be used correctly, 
because the underlying driver state can't actually be copied, and the 
copy ctor could only move. These are the only two that I can ever 
remember that were worth removing for the user's sake. I actually 
thought qsnprintf() was one, too, but then I considered an Android-only 
app that happily uses qsnprintf("%ls", qUtf16Printable(string)), whose 
port to std::snprintf() would be non-trivial. So I no longer consider 
even qsnprintf() to be a removal candidate.

About Qt5Compat: there's still no replacement for QTextCodec, and I 
don't understand why it was ever moved out of QtCore. As a consequence, 
the first few Qt 6 releases weren't able to parse XML files with 
shift-jis encoding, a Qt 5 regression, still unfixed, except for libicu 
builds.

Ditto QStringRef. We broke QStringRef -> QStringView conversion in the 
process of ripping QStringRef out of QtCore, and we left the XML classes 
with a minimal reimplementation of QStringRef that shares no code with 
the latter.

Even QRegExp porting isn't trivial: QRegularExpression doesn't cache the 
compiled pattern, but QRegExp did, so you can get quite nasty 
performance degradation if you keep re-constructing the same 
QRegularExpression in a tight loop, while QRegExp would "behave".

Summary: I see no reason, from a user perspective, to remove qt5support 
from Qt 7. Maybe we can make more fine-grained libraries libQTextCodec, 
libQRegExp, libQStringRef instead of using the "Qt N Compat" moniker and 
artificially binding them together. Like QT_NO_X instead of 
QT_DEPRECATED_V_X, that lets users tackle deprecated APIs at their own 
pace, in their own order, without being hit by these walls of changes 
with every Qt version. Something we ourselves have recently gotten a 
dose of when we tried to bump the QT_VERSION to 0x061000...

                    -- Do unto others as you would have done to you.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at qt.io> (he/his)
Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io

Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B