Proposal on improvement to deprecated

[Andrei Alexandrescu]

On 10/2/11 10:57 PM, Walter Bright wrote:
> On 10/2/2011 8:47 PM, Jonathan M Davis wrote:
>> Well, making deprecation print messages but not prevent code
>> compilation and
>> then later completely preventing code compilation when you make it "full"
>> would better deal with the use case that you're always having problems
>> with of
>> code being broken as soon as something is deprecated. It'll make it so
>> that
>> programmers get a message (which they may be able to turn off with -d)
>> rather
>> than their code breaking, and then when the item would have been removed,
>> rather than their code just breaking, it breaks (since the item has
>> been fully
>> deprecated and is unusable), but they get a decent message about how
>> to fix it.
>> The end result is much less disruptive and not much more complicated
>> than what
>> we have now.
>
> I don't see it as less disruptive. I see no point to anything beyond -d
> to allow deprecations, and no -d to not allow them. The only real point
> of -d is so the user can defer fixing it until it is convenient; it's
> not meant as a permanent part of one's build process.

I agree. Perhaps the best solution is to simply allow a message with 
deprecated. This will allow library writers to control the "strength" of 
deprecation by simply adjusting the message from "This will be 
deprecated on yyy-mm-dd" to "This is now deprecated and unsupported".

Andrei