Proposal on improvement to deprecated

[Aleksandar Ružičić]

What about using an attribute for that?

deprecated("foo() is deprecated use bar()") void foo() {...}
@schedule deprecated("foo() is going to be deprecated as of YYYY-MM-DD, use 
bar() instead") void foo() {...}

First form will behave like just it does now, with optional message 
argument.
Second form would produce informational message instead of compile error 
(with line number where that symbol is accessed from).

Both forms would print nothing when using -d switch.

In case "unavailable" is required, another attribute could be used for that:

@removed deprecated("foo() was removed as of YYYY-MM-DD, use bar() 
instead.") void foo();

When @removed deprecated symbol is used compiler will abort with detailed 
error message (line number where symbol is accessed from) even if -d switch 
is used. This would be more convenient than just bailing out with message 
"undefined symbol foo()" because we can  use message parameter of deprecated 
to direct user where to look for replacement.

Of course @schedule and @removed names are just an example..


"Jonathan M Davis"  wrote in message 
news:mailman.29.1317612078.22016.digitalmars-d at puremagic.com...

On Sunday, October 02, 2011 07:06:36 Michel Fortin wrote:
> On 2011-10-02 05:24:36 +0000, Jonathan M Davis <jmdavisProg at gmx.com> said:
> > deprecated("message", soft) void func1() {}
> > deprecated("message", hard) void func2() {}
>
> This soft/hard thing is a little obscure, no one will understand what
> it means by looking a it. Why not have separated 'deprecated' and
> 'unavailable' states?

We could just do

deprecated("message");
deprecated("message", full);

"Full" deprecation should be clear enough, I would think. And for 
simplicity,
you just don't have any argument for partial deprecation.

- Jonathan M Davis