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.digitalmar...@puremagic.com...
On Sunday, October 02, 2011 07:06:36 Michel Fortin wrote:
On 2011-10-02 05:24:36 +0000, Jonathan M Davis <jmdavisp...@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
