dmd 1.069 and 2.054 release

[Jonathan M Davis]

On Sunday 10 July 2011 21:54:42 Jonathan M Davis wrote:
> On Monday 11 July 2011 14:26:32 Daniel Murphy wrote:
> > "Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message
> > news:mailman.1520.1310357559.14074.digitalmars-d-announce at puremagic.com.
> > ..
> > 
> > > Now, if deprecated were improved to take a message (and to allow for
> > > soft
> > > deprecation, since the messages printing here are about stuff being
> > > scheduled
> > > for deprecation rather than actually being deprecated yet), then
> > > maybe
> > > they
> > > could give a useful file and line number (at least for the
> > > functions),
> > > since
> > > then the compiler would know that a function was scheduled for
> > > deprecation and
> > > could warn you about using it. But since the best that we have for
> > > that
> > > is pragmas, that doesn't work. And actually, without that sort of
> > > feature, any
> > > function that isn't a template can't even have such a message - at
> > > best
> > > it can
> > > have a note in the documentation.
> > 
> > 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.
> 
> Essentially, what's needed is the ability to give a message to the deprecate
> attribute _and_ the ability to make the deprecation "soft" when it's
> something which is scheduled for deprecation and not yet actually
> deprecated. e.g.
> 
> deprecated("message", hard)
> deprecated("message", soft)
> 
> or maybe
> 
> deprecated("message", full)
> deprecated("message", scheduled)
> 
> Obviously, the message can't be required, and the default if no deprecation
> type was given (soft or hard) would be hard so that you could still use
> deprecated the way that we do now. But by allowing for the extra arguments,
> it would be possible give a message for full/hard deprecation as well as
> indicate that something is only scheduled for deprecation.
> 
> With that implemented, it would fix the problem for functions, but I'm not
> sure that it would fix the problem for modules. That would depend on how it
> was implemented. As it stands, if you deprecate an entire module, you end
> up doing something like
> 
> deprecated:
> 
> at the top of the module, which is then going to complain about each symbol
> in the model individually when you use it. Ideally, you could make it
> complain about the module when it's imported (and then maybe the specific
> functions on top of that), and that syntax doesn't really give you that. It
> just makes it complain about the symbols when you use them. But that can
> work too.

*Sigh* I really need to kill the shortcut in my e-mail client for sending 
messages. I was about to say that an implementation of 
http://d.puremagic.com/issues/show_bug.cgi?id=5481  _is_ essentially what we 
need but that your example seems to show a lack of understanding of the 
feature (particularly with regards to "scheduled for deprecation" rather than 
full deprecation).

- Jonathan M Davis