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
