chehrlic added a comment.
In D23789#538985 <https://phabricator.kde.org/D23789#538985>, @kossebau wrote: > >> - why has all Qt code not yet been adapted to QT_DEPRECATED_VERSION/QT_DEPRECATED_VERSION_X, are there places where those macros should not be used, but the version-less ones? > > > > Because noone wanted to do the work and it was added late in the Qt5 lifetime -> A lot of stuff was deprecated for a long time already (in Qt4 times) and there is was a replacement since Qt5.0.0 so the macro was not needed (even though a lot of people got very angry about it). I added it for some new signals which created a lot of discussion since the old ones are widely used. > > Can you point to those discussions? Would be curious to learn what people's thought are. https://lists.qt-project.org/pipermail/development/2019-March/035343.html It's most likely a discussion when a deprecated / replaced function should really create a warning (esp. when the replacement was just recently added) and when the function should be removed completely - should a function deprecated in Qt5 really be removed in Qt6 or wait for Qt7 or don't remove it at all. > > >>> - why did you go for both QT_DEPRECATED_VERSION & QT_DEPRECATED_VERSION_X, are there places where no message will be wanted? >> >> Just for consistency - we've QT_DEPRECATED and QT_DEPRECATED_X but I think QT_DEPRECATED should be deprecated by itself. I hope no reviewer will accept a QT_DEPRECATED anymore. > > So you would also think that message-less variants will not be needed I understand. Okay. From what I tested with experimentally deploying the macros on some KF modules I almost always could add a useful message, so running short of reasons for keeping a message-less variant :) I think it should be enough to have one macro nowadays :) REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D23789 To: kossebau Cc: chehrlic, dfaure, cgiboudeaux, kde-frameworks-devel, kde-buildsystem, LeGast00n, GB_2, bencreasy, michaelh, ngraham, bruns
