[Suggestion] More deprecation features

[Stewart Gordon]

"Don" <nospam at nospam.com.au> wrote in message 
news:g5pfl7$1cfr$1 at digitalmars.com...
<snip excessive quote>
> 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?

Let's see ....

For idea 1, I suppose you could do

    version (deprecated) {
        public void deprecatedlyPublicFunction() { ... }
    } else {
        private void deprecatedlyPublicFunction() { ... }
    }

but quite a bit of duplication of code would be involved.  OK, so you could 
make them both wrap a third function, but it's still a long way round.

I guess the workaround that's already been mentioned would work better.  The 
notation I proposed for deprecation-dependent protection attributes would 
make for more concise code than either idiom.

For idea 2 ....

    version (deprecated) {
        final void callback() { ... }
    } else {
        void callback() { ... }
    }

That said, some of the above comments probably apply here as well.

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

Not sure about this.

But if we had version (deprecated), I guess we could do away with deprecated 
as an attribute altogether.  Indeed we'd have to, in order to free up the 
keyword so that it can be a version identifier.

But having deprecated as an attribute does have some use: it enables 
compiler messages to be more to the point than if we just deprecated stuff 
by versioning it out.  Consequently, expanding the built-in concept of 
deprecation would be an improvement to the language.

Stewart.

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