Let me add a preface that I probably should have added initially:
Understand that I am, of course, aware of the maintenance cost aspect of
not removing deprecated APIs, esp. modules. I am also aware that, as a
commercial entity, TQtC is free to set their priorities as they wish and
see fit. But Qt is not only a commercial offering, but also a libre
software project with non-commercial users, and I'm playing devil's
advocate here.
With my Qt developer hat on (even with the Qt project hat on), I am not
exactly thrilled at the prospect of having to carry deprecated APIs
around for longer (or "-ever"), but if the price that allows me to
deprecate APIs I find should no longer be used in new projects is to
have to maintain those APIs as if they were not deprecated, then I'm all
for it.
I just want to know that I'd not be alone in this. Because, as
mentioned, the whole thing only gives a user benefit if a majority of
APIs fall under the new rule.
The alternative to deprecation is to use something else to mark APIs as
not desirable for new projects. We have, e.g.,
QT_ENABLE_STRICT_MODE_UP_TO. But I find it important to have the
compiler (optionally!) warn about such APIs in a by-the-way kind of way,
instead of relying on user projects to always maintain compat with the
latest STRICT_MODE, violations of which are hard compile errors and not
just warnings.
And I think that the fine-grained deprecation warning controls we have
(at the version level, at least), are already pretty good for that. We
can, of course, always improve and make the deprecation macros
per-module to give users even more control, but then we're getting close
to overlap with QT_ENABLE_STRICT_MODE_UP_TO, which is just a convenience
macro to handle extremely-fine-grained QT_NO_ opt-outs gracefully. But I
guess it wouldn't be _that_ hard to make the deprecation macros
per-module, if that would help people?
Thanks,
Marc
On 14.01.25 22:15, Marc Mutz via Development wrote:
> 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
