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
