dmd 1.069 and 2.054 release

Leandro Lucarella luca at llucax.com.ar
Tue Jul 12 13:52:10 PDT 2011


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 :)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
All evidence has been buried
All tapes have been erased
But your footsteps give you away
So you're backtracking
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-option-to-show-deprecated-errors-as-warnings.patch
Type: text/x-diff
Size: 29050 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-announce/attachments/20110712/f26b210f/attachment-0001.patch>


More information about the Digitalmars-d-announce mailing list