dmd 1.069 and 2.054 release

[Jonathan M Davis]

On Monday 11 July 2011 15:31:11 Daniel Murphy wrote:
> "Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message
> news:mailman.1523.1310360242.14074.digitalmars-d-announce at puremagic.com...
> 
> > *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).
> 
> Well, that is why I asked.  Yes, what I'm proposing is not exactly what was
> in the bug report.
> 
> The way it seems to be done, removing a feature has three stages:
> 1. schedule for deprecation
> 2. mark as deprecated
> 3. remove it
> 
> The point of stage 1 seems to be to warn the programmer that some time in
> the future they're going to need -d to compile their code.  I'm really not
> convinced that this message should always be displayed, as most of the time
> it's useless noise.  It does however make sense to print it out when
> compiling with -v or generate a warning when compiled with -w (or -wi).
> 
> Then again, maybe 'scheduled for deprecation' is something that should be a
> lower level than warning. (If D had warning levels)  In this case it should
> still only print with -v or -w.

A message needs to be printed in stage 1. Whether it should always be printed 
is debatable. But without the message, unless the programmer is re-reading the 
documentation, they won't see that something has been scheduled for 
deprecation. On some level, the programmer _should_ be bugged about it, 
because they need to change their code, but on the other hand, it's scheduled 
for deprecation rather than deprecated precisely so that the programmer has 
time to change their code before the item in question is deprecated, so always 
bugging about it doesn't really make sense either. So, making it so that it 
only prints with -v or -w is probably fine. But regardless, the whole point is 
to alert the programmer so that they have the chance to change their code 
before they need to start compiling with -d. So, the message needs to be 
there, but I'm not sure that I really care that much about whether it always 
prints or not. Having it always print with -w, -wi, or -v but otherwise not 
print is probably fine.

> > 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.
> 
> Ok, would this be fixed by allowing:
> deprecated module mymodule;
> and the rest of it?

I think that it's all been covered. Stage 1 needs an appropriate message and a 
way to put that message on specific symbols (and possibly modules). Stage 2 
currently works as-is but would be better with a message. And, of course, 
stage 3 works quite well without any features at all.

So, overall I think that that covers it. The exact details of how it interacts 
with compiler flags is up for some debate, and I'm not sure that I care a whole 
lot about how that's dealt with except that the messages for stage 1 need to 
be seen, so they need to be displayed when a reasonable set of compiler flags 
is used. Otherwise, the deprecation will come to surprise to people and cause 
them even more problems.

- Jonathan M Davis