Proposal on improvement to deprecated

Walter Bright newshound2 at digitalmars.com
Sun Oct 2 20:57:37 PDT 2011


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.


More information about the Digitalmars-d mailing list