dmd 1.069 and 2.054 release

[Jonathan M Davis]

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