dmd 1.069 and 2.054 release

[Andrew Wiley]

On Mon, Jul 11, 2011 at 2:10 PM, Jonathan M Davis <jmdavisProg at gmx.com>wrote:

> On 2011-07-11 13:50, Nick Sabalausky wrote:
> > "Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message
> > news:mailman.1539.1310416341.14074.digitalmars-d-announce at puremagic.com.
> ..
> >
> > > On 2011-07-11 13:09, Nick Sabalausky wrote:
> > >> Not that I feel strongly about it, but just like "scheduled for
> > >> deprication", actual warnings are things that *are* valid code, too.
> Ie,
> > >> they're just messages, too. The whole point of a "warnings as errors"
> > >> setting is that some people want that extra help to ensure their code
> is
> > >> perfectly pristine. (Although, personally, I've never seen
> particularly
> > >> strong reason for "warnings as errors" settings anyway.)
> > >>
> > >> To be clear, if we did have some "deprecated(scheduled)" feature and
> it
> > >> was
> > >> non-fatal even with -w, I wouldn't personally have a huge problem with
> > >> it (I never use -w anyway, just -wi). I just don't think it's so
> > >> clear-cut that "scheduled for deprication" doesn't essentially amount
> > >> to a warning.
> > >
> > > Hmm. The main problem with making the scheduled for deprecation
> messages
> > > being
> > > treated as errors with -w is that if you build with -w (as a lot of
> > > people do), it breaks your code. And the point of the message is to
> warn
> > > you that your code is _going_ to break and to _avoid_ causing immediate
> > > breakage.
> >
> > If someone doesn't want warning conditions to break their code, they
> should
> > be using -wi, not -w.
>
> 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. 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.


I would argue that when you compile with -w (and explicitly -w, not -wi),
you're explicitly asking the compiler to break your code for warnings, and I
believe that should include code scheduled for deprecation. By specifying
-w, you're explicitly asking the compiler to check your code more strictly,
and I see more aggressive deprecation as an acceptable part of that.

To paraphrase your description, there's something that's about to break in
your code, but it's not broken yet, so if you drop -w (or switch to -wi),
you can still build it. If we're taking the approach that warnings break
code when -w is used, I see scheduled deprecations falling into a very
similar category.

And no, this change doesn't obsolete code deprecation, it simply extends the
higher standards that -w holds you to into the library space. If you don't
want "scheduled for deprecation" to break your code, use -wi. You'll get all
the same noise you got before, just without the breakage.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-announce/attachments/20110711/02a5ee46/attachment-0001.html>