a small study of "deprecate"

[Don Clugston]

On 07/11/12 14:16, monarch_dodra wrote:
> There is some talk going on right now of changing "deprecate" into a
> UDA. There are some people saying that deprecate is broken, and
> proposing some fixes (myself included). Instead of concentrating on how
> to "fix" it, and like to first study "what" is broken.
>
> ----
> What exactly is supposed to be the lifetime of a deprecated function?
> What (default) behavior do we expect from deprecated?
>
> **Timeline**
> 1. The function can be used normally.
> Nothing to say here.
>
> 2. The function is *marked* for deprecation.
> At this point, the user would like to be served with a warning, that he
> should consider migrating to a new function.
>
> 3. The function is fully deprecated. At this point, the user shouldn't
> be using it anymore, but if he really really wants to, he should be able
> to.
>
> 4. The function is blasted out of existenc.
> ----
>
> The problem, IMO, comes from the fact that we actually have no way to
> implement "2". Because of this, there is a major gap in our deprecation
> process.

You are quite wrong. The problem is 3. There's actually nothing wrong 
with "deprecated", the problem is the -d command line option.
Suppose you want to continue using the function. There is no reasonable 
way of doing it. If you use the -d option, you will not be notified 
about 2. If something else is deprecated, you won't find out about it.

Basically -- a warning should ALWAYS be printed for deprecated 
functions, even if you are using -d. It's that simple.

There is a pull request to fix this situation. I don't know why this 
discussion is happening.