dmd 1.069 and 2.054 release

[Jonathan M Davis]

On 2011-07-12 13:52, Leandro Lucarella wrote:
> Jonathan M Davis, el 12 de julio a las 18:12 me escribiste:
> > > > 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.
> 
> So then, why don't we fix it (patch attached, you can apply it with 'git
> am file'). I think -di is the real solution to the problem. Things are
> deprecated or not, and people want to be informed if they are using
> something deprecated or not. Scheduled for deprecation seems to be a way
> to say "show me a deprecation message", not a real "state".
> 
> > 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.
> 
> OK, then we should fix the compiler (again, patch attached). -di is the
> solution. My patch doesn't change the defaults, but if people think is
> better to show deprecation errors by default, it can be trivially
> changed.
> 
> > 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.
> 
> This is what deprecated is for! Removing stuff breaks code, not
> deprecating stuff! Deprecated really is "scheduled for removal", so
> "scheduled for deprecation" is "scheduled for scheduled for removal", it
> makes no sense. Fix the compiler!
> 
> > 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.
> 
> Unless we fix the compiler :)

This doesn't really fix the problem. Deprecating something is still going to 
break code unless people actively try and avoid it by using -di, so 
deprecating stuff without informing people beforehand is going to break a lot 
of code. Perhaps the language should be change so that using deprecated stuff 
generates a warning rather than an error, but unless you change the default 
behavior, the original problem still stands.

If you want how the language treats deprecated to change, then feel free to 
create a pull request and try and talk Walter into it. Arguably, warning about 
deprecation and then only failing to compile when the deprecated stuff is 
actually removed is the better way to handle things. But that's not how D is 
designed (probably at least in part because Walter doesn't really believe in 
warnings). So, feel free to try and talk Walter into it, but unless the 
default behavior is changed, deprecating something is going to silently break 
people's code unless you tell them about it first (which is the point of 
scheduling something for deprecation).

- Jonathan M Davis