Den mån 22 okt. 2018 kl 00:14 skrev Giuseppe D'Angelo via Development
Hi,
Post by Christian Ehrlicherthere are a lot of deprecated functions in qtbase which are only marked
as deprecated/obsolete in the documentation but don't have a
Q_DECL_DEPRECATED. Most of them were deprecated in the pre Qt5-era.
What's the 'correct' way to make sure they can be removed with Qt6? Must
they marked as QT_DEPRECATED_SINCE(5,x) or is the comment in the
documentation enough?
The documentation comment is enough for us to justify the removal -- in
other words, "formally", we have informed the user to move away, and the
rule is that we can drop deprecated functions any time we want to break
source compatibility.
However, it's nowhere enough to
1) make users _aware_ of the fact that they're using deprecated APIs;
2) make us _remember_ to remove those functions when we have the chance
(like in Qt 6).
users get the deprecation warnings (*), and we have an easy way to find
and drop all those functions.
* If possible, all the code to be killed in Qt 6 should already be
protected via
Post by Christian Ehrlicher#if QT_VERSION < QT_VERSION_CHECK(6, 0, 0)
* Add some comment in the source code like
// ### Qt 6: remove this
Both ways are more general and apply to functions we can't just
deprecate or remove (f.i., marking an overload to be merged with another
one via a default argument, getting rid of useless special member
function declarations, and the like).
Of course, simply leaving a comment requires us to remember find those
usages and act on those, and the code is still full of such TODOs for Qt
5...
(*) I don't like that the deprecation warnings are opt-in and not
opt-out. People deserve to know as soon as possible that they're using
deprecated functionality, rather than have a gigantic unpleasant
surprise ("you're using lots of deprecated stuff that got removed!")
when Qt 6 comes.
+1 for opt-out from a user.
I had forgotten to add this to the build of our application. Will be