dmd 1.069 and 2.054 release

[Nick Sabalausky]

"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).

> It's just
> not wrong enough to be against the language spec and therefore always be 
> an
> error. Scheduling something for deprecation is indicating that the symbol 
> in
> question will be deprecated in the future and that you should change it 
> before
> that happens. Your code is still fine, and it should still compile.
>
> Bottom line. Marking something as "scheduled for deprecation" should 
> _never_
> break code no matter what flags you use to compile your code. Otherwise,
> there's no point to it, and we'd just be deprecating stuff immediately.
>
> - Jonathan M Davis