[Suggestion] More deprecation features

[Stewart Gordon]

Now that most of the rusty old deprecation bugs have finally been squashed 
(if you'll excuse the mixed metaphor), here are a few ideas I've had for a 
while for taking the concept of deprecation further.


1. Sometimes it's useful to deprecate something, but keep it for internal 
use.  So effectively it's private, except if compiling with -d, in which 
case it will be public.  The notation might look something like

    private deprecated public void qwert() { ... }

The error message on trying to use it from outside might look something like

    qwert.d(42): function qwert is deprecated for public access

Other combinations of access levels would be similarly allowed, of which 
these make sense IMM:

    private deprecated package
    private deprecated protected *
    private deprecated public *
    private deprecated export *
    package deprecated public *
    package deprecated export *
    protected deprecated public
    protected deprecated export
    public deprecated export

Overriding of methods with the asterisked protection settings would be 
allowed only if the derived class method is also deprecated (or -d is 
specified).  To declare a method with the same name and parameters in a 
derived class, without specifying either the deprecated attribute or the -d 
switch, would be an error.  This is necessary to the principle of 
deprecation, i.e. code that compiles without -d doesn't change its behaviour 
when -d is specified, and existing code can still compile.

Of course, implementing this would affect how attributes are parsed.  I 
suppose the best idea would be to treat each possible case of the word 
"deprecated" immediately between two protection attributes as a protection 
attribute in its own right in terms of the way they override each other.


2. A means of deprecating callbacks.  That is, deprecating overriding of a 
method rather than using it.  This makes sense as callbacks are going to 
want replacing from time to time, just as callforwards :-) are.  The base 
class would keep its calls to the method, so that old code will still work, 
but new or modernised code would not be overriding it anymore.

(This would be provided at least to some extent by idea 1....)


3. Deprecating modules.  Currently, the compiler doesn't allow modules to be 
declared as deprecated.  A module being deprecated may signify:

- that the whole API area that it is there to support is deprecated, either 
because it's an obsolete technology or because it's been superseded by 
another module

- that the module has been renamed, and all the old one does is imports the 
new one for compatibility

- that it was used for development/testing purposes and is no longer needed


4. Deprecated imports.  So effectively, any attempt to use anything from the 
imported module would throw a deprecation error, unless a non-deprecated 
import of the same module is also visible from the scope where the use 
occurs.  This might be to prevent the compiler error that would otherwise be 
caused by importing a deprecated module for use by deprecated code.  Or to 
phase out a public import that was figured to be a bad idea.


Comments?

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies 
on the 'group where everybody may benefit.