a small study of "deprecate"

[Jonathan M Davis]

On Wednesday, November 07, 2012 15:05:05 deadalnix wrote:
> Here is how I see it (and all language fail at that as far as my
> knowledge goes).
> 
> Deprecation comes with a date and a message.
> 
> Before the date, the dev is presented with the deprecation message when
> compiling. The message explain why the function is deprecated and what
> to use instead.
> 
> After the date, the message pops, but now it is an error (unless some
> flag is used).
> 
> At some point the function may be removed.

Date-based stuff was discussed previously and rejected. One of the major 
reasons that it doesn't work is that there are times when you want to 
deprecate based on versions rather than dates. But the _really_ big reason not 
to do that is that if compile my code with version X of the compiler, it 
should _always_ compile with version X of the compiler. It would result in a 
big maintenance problem if you couldn't go back and rebuild older versions of 
a program (or just an older program) with the compiler that it was originally 
compiled with. It's one thing if it won't compile with a newer version of the 
compiler or a newer version of the library, but not compiling with the same 
version that it was developed with causes big problems later down the line, 
especially if you're dealing with a program that doesn't get worked on very 
often.

So, while giving a message that a particular symbol is going to be deprecated 
on a certain date is fine, having the compiler deprecate it for you at that 
date is going to cause problems.

- Jonathan M Davis