a small study of "deprecate"

[Jonathan M Davis]

On Wednesday, November 07, 2012 14:16:26 monarch_dodra wrote:
> I'm not going to propose a solution in this post, but I think
> this is a good starting point for more discussion. Thoughts?

There's a relatively easy solution to this - just add the concept of soft and 
hard deprecation. Then, in additon to deprecate taking a message (which it 
finally does now), it could take a value indicating the level of deprecation. 
e.g.

deprecated("use X instead", soft) void func();

or

deprecated("use X instead", hard) void func();

or

deprecated("use X instead", false) void func();

or

deprecated("use X instead", warning) void func();

or whatever we decided to use for the argument to indicate the level of 
deprecation. But soft would mean that only a warning was given, whereas hard 
would mean that you'd get an error. Then you make either soft or hard the 
default (hard would keep the current behavior) so that if it's not provided, 
that's what's used. You then have normal -> soft -> hard -> gone.

The problem is that when this was brought up before, Walter didn't want to do 
anything ilke this, because he thought that it complicated the feature too 
much. He liked deprecated being nice and simple. It probably doesn't help that 
he doesn't like the idea of anything being deprecated in Phobos, and Phobos 
was the main reason that such a feature change was being requested.

So, I don't know what the odds of being able to get something like this are. 
It's certainly what _I_ would like to see implemented though.

- Jonathan M Davis