[Suggestion] More deprecation features

[BCS]

Reply to Stewart,

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


Another solution would be to rename the old function (foo -> foo_int) patch 
up all internal references and then make a deprecated wrapper function or 
alias to make the external calls work. That patch up should be doable because 
if you don't have that code in hand. it probably isn't internal.