[Development] On deprecating functions

[André Pönitz]

On Mon, Mar 04, 2019 at 12:21:09PM -0800, Thiago Macieira wrote:
> 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"?

Some will if there is a reasonable way to do it. And that means
that the intended solution ("change the code") needs to be less
ugly than either possible workaround.

It also means that fixing warnings overall should take
(significantly) less effort that "normal development" for the
"product".

> > 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

I maintain that it  *might* solve the problem, as in that case
there would be a change to the code that's not an obvious
uglification, at some time. This is currently not possible, 
as the intended solution (switch over to the (QString) signals)
is simply not compilable in all required setups.

Of course, there's no *guarantee* that this will happen when it
is compilable, but so far it *did* happen in comparable situations.

> 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).

The point in question is to get a warning *without* having a
reasonable option to act on it.
> 
> 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.

The proposed model would effectively introduce another user-visible
level including associated period of time between "alternative
solution gets introducd" and "getting nagged about not using it"
that is "hopefully" long enough, to cover "most interesting"
(to be blunt: read: "including my") use case.

Andre'