[Suggestion] More deprecation features

[superdan]

Don Wrote:

> Stewart Gordon wrote:
> > 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.
> > 
> 
> Suppose there was version(deprecated), which is set only if -d is used 
> on the command line. Wouldn't that let you do most of these things?
> 
> Eg, point 3 and 4:
> 
> module reallyold;
> version(deprecated) {
> import anotherdeprecatedmodule;
> } else static assert(0, "This module is deprecated");
> 
> Sure, it's a bit ugly, but it's simple and would give a lot of 
> flexibility. BTW this could be added to D1.0.

fuckin' a. by the same token i needed version(unittest) to include shit only if unit testing is on. i could also use version(function), version(class), version(struct), and version(module) to figure out from inside a mixin whether it is being expanded inside a function, class, struct, and respectively module. but i guess this is wishful thinkin' shit.