Proposal on improvement to deprecated

[Jonathan M Davis]

On Sunday, October 02, 2011 23:36:13 Andrei Alexandrescu wrote:
> 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".

Except that the code won't compile regardless of whether the message says that 
the symbol is going to be deprecated or that it has been deprecated. In either 
case, the symbol has been deprecated as far as the compiler is concerned, 
regardless of what the message says. So, the strength of the deprecation is 
identical in either case. The only difference is whether the library writers 
will fix any bugs found in such a deprecated function. In both cases, the 
programmer is either going to have to immediately change their code or add -d 
to their bulid process.

I really think that making it so that deprecated doesn't actually stop 
compilation (but rather just prints the message) would improve things even if 
we didn't add any kind of level to deprecated that would always stop 
compilation prior to the symbol actually being removed.

- Jonathan M Davis