<div class="gmail_quote">On Mon, Jul 11, 2011 at 2:10 PM, Jonathan M Davis <span dir="ltr"><<a href="mailto:jmdavisProg@gmx.com">jmdavisProg@gmx.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div><div></div><div class="h5">On 2011-07-11 13:50, Nick Sabalausky wrote:<br>
> "Jonathan M Davis" <<a href="mailto:jmdavisProg@gmx.com">jmdavisProg@gmx.com</a>> wrote in message<br>
> news:mailman.1539.1310416341.14074.digitalmars-d-announce@puremagic.com...<br>
><br>
> > On 2011-07-11 13:09, Nick Sabalausky wrote:<br>
> >> Not that I feel strongly about it, but just like "scheduled for<br>
> >> deprication", actual warnings are things that *are* valid code, too. Ie,<br>
> >> they're just messages, too. The whole point of a "warnings as errors"<br>
> >> setting is that some people want that extra help to ensure their code is<br>
> >> perfectly pristine. (Although, personally, I've never seen particularly<br>
> >> strong reason for "warnings as errors" settings anyway.)<br>
> >><br>
> >> To be clear, if we did have some "deprecated(scheduled)" feature and it<br>
> >> was<br>
> >> non-fatal even with -w, I wouldn't personally have a huge problem with<br>
> >> it (I never use -w anyway, just -wi). I just don't think it's so<br>
> >> clear-cut that "scheduled for deprication" doesn't essentially amount<br>
> >> to a warning.<br>
> ><br>
> > Hmm. The main problem with making the scheduled for deprecation messages<br>
> > being<br>
> > treated as errors with -w is that if you build with -w (as a lot of<br>
> > people do), it breaks your code. And the point of the message is to warn<br>
> > you that your code is _going_ to break and to _avoid_ causing immediate<br>
> > breakage.<br>
><br>
> If someone doesn't want warning conditions to break their code, they should<br>
> be using -wi, not -w.<br>
<br>
</div></div>Yes. But the problem is that the "scheduled for deprecation" messages are not<br>
supposed to _ever_ break code. And since warnings aren't normally added very<br>
often, compiling with -w shouldn't cause your code to suddenly break. Granted,<br>
dmd is still unstable enough that such changes do occur, but once it's fully<br>
stable, it wouldn't happen very often. But anyone can schedule something for<br>
deprecation in any library, and the whole point of _scheduling_ the<br>
deprecation instead of just deprecating it is to avoid breaking code. So, it's<br>
unacceptable for scheduling something for deprecation to be an error with -w.<br>
It's informational only. Warnings are _not_ only informational. They're<br>
telling you that there's actually something wrong with your code. It's just<br>
not wrong enough to be against the language spec and therefore always be an<br>
error. Scheduling something for deprecation is indicating that the symbol in<br>
question will be deprecated in the future and that you should change it before<br>
that happens. Your code is still fine, and it should still compile.<br>
<br>
Bottom line. Marking something as "scheduled for deprecation" should _never_<br>
break code no matter what flags you use to compile your code. Otherwise,<br>
there's no point to it, and we'd just be deprecating stuff immediately.</blockquote><div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>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.</div>

</div>