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.m...@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
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
