On Mon, Jul 11, 2011 at 2:10 PM, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
On 2011-07-11 13:50, Nick Sabalausky wrote:
> "Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message
> news:mailman.1539.1310416341.14074.digitalmars-d-announce@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.