On Monday, 4 March 2019 10:46:00 PST Christian Ehrlicher wrote: > You know what happens in this case - nothing since noone notices... see > all the usages of deprecated functions within QtBase which have been > unrecognized for ages.
I do, but who's to say people will fix warnings? Will they do that only because it's now "in their face"? > Lars mentioned a new macro Q_WARN_DEPRECATED_SINCE(major, minor) here: > https://codereview.qt-project.org/#/c/254857/ - maybe this could help here? The grace period for warnings as I'd understood from hjk would not solve the problem. It would only cause the problem to be pushed further down the line, if we take your thesis into account that developers won't solve deprecations until there's a warning. That means they'll still complain, despite having had a grace period (which they didn't know about). Adding a controllable warning setting could help, especially if we default it to the current (or past) release. Codebases that wish to silence those warnings would explicitly push it forward. There'll be codebases that set the warning to 0x057f00... Anyway, how would that be different from our pre-5.12 model, where you'd explicitly enable warnings if you want them. That's why we use QT_DEPRECATED, not Q_DECL_DEPRECATED. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
