a small study of "deprecate"

Regan Heath regan at netmail.co.nz
Wed Nov 7 05:39:41 PST 2012


On Wed, 07 Nov 2012 13:16:26 -0000, monarch_dodra <monarchdodra at gmail.com>  
wrote:
> At this point, I have no solution to propose, but I think I have  
> analyzed the root of the problem: "deprecate" is a two-phase function:  
> "Fine, you can use me no problem whatsoever" to "too late, I'm  
> deprecated! (or even gone)".
>
> The conclusion is that anything short of a "3-state solution" is bound  
> to failure. We need a way to tell apart "2" from "3". Period.
>
> I'm not going to propose a solution in this post, but I think this is a  
> good starting point for more discussion. Thoughts?

I agree we want a 3 stage (at least) deprecation model.

So the timeline would be..
1. feature is usable (normal case)
2. feature is under deprecation "deprecate" (compiler issues a warning)
3. feature is "deprecated" (compiler issues an error)

The warning in state 2 "deprecate" would point the user to the replacement  
feature.

The error in state 3 "deprecated" would be a normal compiler error, but  
have an addition message to point the user to the replacement feature.

In state 2 "deprecate" the code would be present, but annotated with  
"deprecate" to show that it was under deprecation.  The compiler will  
still compile and use the code, but will issue the warning.

In state 3 "deprecated" the code would no longer be present, instead a  
"deprecated" annotation would be present, giving the old feature name  
(symbol) and the additional message.  The compiler will fail to compile -  
issuing the normal error for a missing symbol or what have you then output  
the deprecated annotation/message.

This implies that for stage 3 the compiler has a symbol to deprecated  
message table which it searches on compile time errors (or similar).

Is that the sort of behaviour we want?  It could be more complicated, I'm  
sure, but this seems a nice and simple set of behaviour which would  
achieve the goal of allowing systematic deprecation.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/


More information about the Digitalmars-d mailing list