Proposal on improvement to deprecated

[Jonathan M Davis]

On Sunday, October 02, 2011 20:57:37 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.

It's less disruptive, because code doesn't immediately break when something is 
deprecated (particularly since -d _shouldn't_ be part of on's normal build 
process). If the messages can then be turned off with -d, you get essentially 
the same situation as right now once you compile with -d, except that if there 
is some sort of "full" deprecation beyond that where even -d won't even let 
the code compile, then you get better messages if someone somehow ends up with 
-d in their normal build process (be it by accident or foolishness or 
whatever).

But simply changing deprecation so that it prints a message instead of causing 
compilation failure makes deprecation less disruptive. Obviously, it's 
ultimately disruptive regardless, since the code has to be changed eventually, 
but at least in that case, it doesn't break immediately. As I recall, the main 
reason that you wanted stuff to be "scheduled for deprecation" first was because 
deprecated breaks code immediately, and you wanted people to have a chance to 
change their code before they'd _have_ to change either their code or their 
build scripts for their code to compile. Making it so that deprecated produces 
a message rather than stopping compilation does that.

- Jonathan M Davis