dmd 1.069 and 2.054 release

[Jonathan M Davis]

On Sunday 10 July 2011 21:04:25 Jonathan M Davis wrote:
> On Monday 11 July 2011 03:41:20 Adam D. Ruppe wrote:
> > General annoyance:
> > $ dmd *.d
> > Warning: As of Phobos 2.054, std.ctype has been scheduled for
> > deprecation in January 2012. Please use std.ascii instead.
> > Warning: As of Phobos 2.052, std.date and std.dateparse have been
> > scheduled for deprecation in August 2011. Please use std.datetime
> > instead. Warning: As of Phobos 2.054, std.string.toupper has been
> > scheduled for deprecation in January 2012. Please use
> > std.string.toUpper instead. Warning: As of Phobos 2.054,
> > std.string.tolower has been scheduled for deprecation in January 2012.
> > Please use std.string.toLower instead. arsd/web.d(702): Error:
> > non-final switch statement without a default is deprecated
> > 
> > 
> > 
> > One of these is not like the other - the last line actually tells
> > me where the problem is with a file and line number so fixing
> > it is easy.
> > 
> > 
> > The others just blab stuff out. IMO these scheduled for deprecation
> > warnings are more annoying to me than just having outright errors!
> 
> The deprecation messages are pragmas. They _can't_ give a useful line
> number. For them to be appropriately useful, they'd have to give the file
> and line number where the module was imported (in the case where a module
> is scheduled for deprecation) or the line number where the function was
> used (in the case of a function is scheduled for deprecation). Pragmas
> can't do that.
> 
> Now, maybe the pragma messages shouldn't have be prefaced with warning
> (since they're _not_ a compiler warning), but there's no way for them to
> give file and line numbers. They're doing the best that they can.

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.

So, yes. The current messages leave something to be desired, but we'd need the 
deprecated attribute to be improved to take a message and a level of 
deprecation (soft vs hard) in order for the situation to be improved.

- Jonathan M Davis