dmd 1.069 and 2.054 release

[Jonathan M Davis]

On 2011-07-11 13:09, Nick Sabalausky wrote:
> "Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message
> news:mailman.1536.1310408114.14074.digitalmars-d-announce at puremagic.com...
> 
> > On 2011-07-11 09:34, Nick Sabalausky wrote:
> >> "Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message
> >> news:mailman.1522.1310360091.14074.digitalmars-d-announce at puremagic.com.
> >> ..
> >> 
> >> > On Monday 11 July 2011 14:26:32 Daniel Murphy wrote:
> >> >> Would the following cover all the common use cases? (Phobos seems to
> >> >> be
> >> >> the
> >> >> biggest user of deprecated so far)
> >> >> 
> >> >> deprecated("message") int a;
> >> >> deprecated("message", warn) int b;
> >> >> 
> >> >> With deprecated(warn) messages only being displayed with warnings
> >> >> enabled.
> >> > 
> >> > No. That's not quite right. If something is actually deprecated, -d is
> >> > required to compile using it. Being able to have a message with it -
> >> > e.g.
> >> > deprecated("message") - would be very useful, because it could tell
> >> > you what
> >> > you're supposed to use instead (or that nothing is replacing it if
> >> > that's
> >> > the
> >> > case). Error vs warning has nothing to do with it. Now, it could be
> >> > that
> >> > compiling with -w would result in the message being printed even if
> >> > you compiled with -d, but that's debatable.
> >> > 
> >> > In the case of something which is scheduled for deprecation, the code
> >> > should
> >> > compile regardless. A message would print if that symbol were used,
> >> > but beyond
> >> > that, nothing happens. That _could_ be made so that it only prints
> >> > when you
> >> > compile with -w, and if it's classified as a warning, then that would
> >> > make sense, except that it shouldn't stop compilation even if
> >> > compiling with -w, so
> >> > it can't really follow what warnings normally do with -w. So, how it
> >> > should
> >> > function with regards to -w is debatable.
> >> 
> >> Despite the confusing non-standard descriptions in --help, -w is the
> >> "Treat
> >> warnings as errors" setting, so it *should* stop compilation - that's
> >> the whole point of -w. The proper "Turn warnings on" setting is -wi,
> >> not -w.
> > 
> > True. But when we're dealing with messages for something which is
> > scheduled
> > for deprecation, they're _not_ warnings. They're messages. They should
> > never
> > cause compilation to fail. What the best way to handle when they print or
> > not
> > is debatable, but they should never cause compilation to fail. So, even
> > if they were printed because -w was used, they still shouldn't be
> > errors. Personally, I'd probably just have them always print (and
> > possibly include a
> > separate flag for turning them off), but even if -w were used for
> > enabling them, they shouldn't be errors. They're just messages. It's
> > stuff that's actually deprecated that affects compilation.
> 
> 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.

So, I don't know what the best way to handle to scheduled for deprecation 
messages is, but they really shouldn't cause code to not compile or force you 
to use a specific flag to make your code compile. Otherwise, we might as well 
just fully deprecate them from the get-go.

The simplest way is to just always print the messages until you fix your code, 
but that could be annoying. So, I don't know. But scheduled for deprecation 
messages must not break code.

- Jonathan M Davis