dmd 1.069 and 2.054 release

[Jonathan M Davis]

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.

So, in the "scheduled for deprecation" stage, programmers are warned that a 
symbol will be deprecated in the near future, but the symbol hasn't been 
deprecated yet, so no code is broken, and no build scripts need to b changed. 
Programmers then have time to rework their code to no longer use the soon-to-
be deprecated symbol without having their code break or having to change their 
build scripts.

If a programmer has not done anything about the symbol before it's actually 
deprecated, then they will have to change their code or change their bulid 
scripts to use -d when the symbol is actually deprecated, but because there 
was the "scheduled for deprecation" phase, the programmer at least had fair 
warning about the impending code breakage and could have avoided it had they 
wanted to.

What it comes down to is that we don't want to suddenly break anyone's code. 
If breaking changes need to be made, we want to provide a smooth path, giving 
people time to rework their code rather than suddenly breaking their code. 
Needing to rework your code can be annoying enough without your code suddenly 
breaking due to a library update.

- Jonathan M Davis