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
