a small study of "deprecate"

[monarch_dodra]

On Thursday, 8 November 2012 at 08:10:36 UTC, Don Clugston wrote:
> 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.

So you are saying: keep the current behavior, but also print a 
warning in -d mode?