On 2011-07-12 10:07, Leandro Lucarella wrote: > Jonathan M Davis, el 11 de julio a las 22:21 me escribiste: > > On Tuesday 12 July 2011 01:28:11 Leandro Lucarella wrote: > > > Jonathan M Davis, el 11 de julio a las 18:15 me escribiste: > > > > > Despite the confusing non-standard descriptions in --help, -w is > > > > > the "Treat warnings as errors" setting, so it *should* stop > > > > > compilation - that's the whole point of -w. The proper "Turn > > > > > warnings on" setting is -wi, not -w. > > > > > > > > True. But when we're dealing with messages for something which is > > > > scheduled for deprecation > > > > > > What's the point of "scheduled for deprecation" anyway? Things are > > > deprecated, or aren't, anything else should be in the documentation. > > > You can always use deprecated features using a compiler, so again... > > > what's the point of "scheduled for deprectation"? I can't really > > > understand that concept. > > > > The idea is to have 3 stages while deprecating something. > > > > 1. Scheduled for Deprecation. > > 2. Deprecated. > > 3. Removed. > > > > When a symbol has been deprecated, -d is required to compile any code > > using that symbol. So, deprecation breaks code. You either have to > > change your code so that it doesn't use the deprecated symbol, or you > > have to change your build scripts to use -d. In either case, deprecating > > a symbol without warning is going to cause problems for anyone > > maintaining code which uses that symbol. > > If you don't want your code to break when something is deprecated, you > should *always* compile with -d, so no, you don't have to change the > build system if you always have -d. Maybe all needed is just a -di (as > in -wi), where deprecation are informed but not treated as errors. > > Scheduled for deprecation makes no sense, it's a user decision to use > deprecated code or not, and if should be a user decision if he/she wants > a warning about deprecated stuff or not.
Except, of course, that good cood generally won't use anything that's deprecated, since the deprecated item is going to go away. The user can decide to use -d and use deprecated code if it makes sense for them, but that really should be decided on a case-by-case basis. Most programmers won't want to use -d. So, they're not going to compile with -d by default. So, deprecating something will break their code. By saying that you're scheduling something for deprecation, you're giving the user time to deal with the change before it breaks their code. Now, I could see an argument for changing how deprecation works so that deprecated has no effect unless a flag turns it on, in which case, the user is deciding whether they want to warned about using deprecated code. In such a case, "scheduled for deprecation" isn't quite as necessary, but then you're just going to break everyone's code when you remove the function (at least everyone who didn't use the flag to be warned about using deprecated symbols). And rather than being able to then change their build scripts to use -d while they fix the problem, they then _have_ to go change their code (or not upgrade their libraries) in order for their code to compile. But that's not how deprecated works in D. When a symbol is deprecated, it's an error to use it unless you compile with - d. So, there is no warning about using deprecated stuff. It's an outright error. It just so happens that you can turn it off if you need to (hopefully as a quick fix). And given that deprecating a symbol introduces errors into the code of anyone who uses that symbol, informing people ahead of time gives them the opportunity to change their code before it breaks. The result is a much smoother process. 1. Something is scheduled for deprecation, so programmers then have the time to figure out what they're going to do to change their code, and they have time to make the changes. Nothing breaks. No one is forced to make immediate changes. 2. The symbol is then deprecated. Anyone who did not take the time to make changes as they were told that they were going to have to do then has broken code, but they have the quick fix of compiling with -d if they need to. They're still going to have to figure out what they're going to do about changing their code, and they're forced to look at the problem at least far enough to enable -d, but their code can still work with some changes to their build scripts. 3. The symbol is outright removed. Programmers have had ample time to change their code, and if they haven't, they now have to. But they were told that the symbol was going away and had to have made changes to their build scripts to even use it this long, so the developer of the library hasn't just screwed them over. The idea is to provide a smooth path for necessary changes. And just deprecating something out of the blue does _not_ do that. - Jonathan M Davis
