dmd 1.069 and 2.054 release

[Jonathan M Davis]

On 2011-07-11 14:32, Nick Sabalausky wrote:
> "Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message
> news:mailman.1542.1310418661.14074.digitalmars-d-announce at puremagic.com...
> 
> > Yes. But the problem is that the "scheduled for deprecation" messages are
> > not
> > supposed to _ever_ break code. And since warnings aren't normally added
> > very
> > often, compiling with -w shouldn't cause your code to suddenly break.
> > Granted,
> > dmd is still unstable enough that such changes do occur, but once it's
> > fully
> > stable, it wouldn't happen very often. But anyone can schedule something
> > for
> > deprecation in any library, and the whole point of _scheduling_ the
> > deprecation instead of just deprecating it is to avoid breaking code. So,
> > it's
> > unacceptable for scheduling something for deprecation to be an error
> > with -w.
> > It's informational only. Warnings are _not_ only informational. They're
> > telling you that there's actually something wrong with your code.
> 
> Something *potentially* wrong. If it actually *knew* that it was wrong it
> would have been an error in the first place, not a warning.
> 
> And "scheduled for deprecation" is literally saying "your code *will* be
> wrong, and you *do* need to address it by X deadline". That's arguably even
> stronger than certain warnings, because some warnings (by the very nature
> of warnings) are false positives.
> 
> I don't really have a problem with the argument that scheduling something
> for deprecation shouldn't break code. But I think that's really more an
> argument against indiscriminate use of "warnings as errors" in general
> (which, again, isn't something I've ever felt a strong need for anyway -
> not that I'm advocating getting rid of it, that would probably annoy some
> people). In any case, the whole point of "warnings as errors" is that the
> user (for whatever possibly-questionable reason) *wants* the compiler to
> bail on anything that isn't guaranteed perfect (to the best of the
> compiler's ability).

Honestly, I would consider it bad practice to leave warnings in code. Leaving 
them in as you're messing with code is fine, because they're not immediately 
fatal, but they _are_ problems. If they weren't, then they shouldn't have been 
warnings in the first place. But I tend to mostly agree with Walter that 
something should either be an error or not. Warnings are for things which are 
definitely wrong but not illegal in the language. Certainly, that's how dmd 
treats them. I know that other compilers love to complain about other stuff 
that doesn't really matter but _could_ be a bug, but once you do that, people 
start letting warnings sit there, and _real_ problems get buried in the mess.

So, obviously, we have a very different view of warnings. But regardless, it's 
going to cause problems if scheduling something for deprecation causes code to 
break. The whole point is to inform programmers that they're going to need to 
change their code soon and to avoid immediate code breakage. Treating 
"scheduled for deprecation" as a warning doesn't do that.

- Jonathan M Davis