dmd 1.070 and 2.055 release

[Lars T. Kyllingstad]

On Thu, 08 Sep 2011 11:49:55 -0700, Jonathan M Davis wrote:

> On Thursday, September 08, 2011 17:52:37 Andrej Mitrovic wrote:
>> Ok cool, my DWin project successfully compiles. The WinAPI bindings are
>> missing extern(Windows) specifiers for its function aliases and 2.055
>> seems to enforce this now, so that api will have to be updated. The
>> only thing that's bothering me is the notices, there's just too many of
>> them.
>> 
>> For example this:
>> 
>> import std.stdio;
>> import std.path;
>> 
>> void main()
>> {
>>     writeln(curdir.rel2abs);
>> }
>> 
>> turns into this:
>> Notice: As of Phobos 2.055, std.path.rel2abs has been scheduled for
>> deprecation in February 2012. Please use absolutePath instead. Notice:
>> As of Phobos 2.055, std.path.isabs has been scheduled for deprecation
>> in February 2012. Please use isAbsolute instead. Notice: As of Phobos
>> 2.055, std.path.getDrive has been scheduled for deprecation in February
>> 2012. Please use driveName instead. Notice: As of Phobos 2.055,
>> std.path.join has been scheduled for deprecation in February 2012.
>> Please use buildPath instead. Notice: As of Phobos 2.055,
>> std.path.rel2abs has been scheduled for deprecation in February 2012.
>> Please use absolutePath instead. Notice: As of Phobos 2.055,
>> std.path.isabs has been scheduled for deprecation in February 2012.
>> Please use isAbsolute instead. Notice: As of Phobos 2.055,
>> std.path.getDrive has been scheduled for deprecation in February 2012.
>> Please use driveName instead. Notice: As of Phobos 2.055, std.path.join
>> has been scheduled for deprecation in February 2012. Please use
>> buildPath instead.
>> 
>> That is just unacceptable imho.
> 
> At present, the only way to get rid of them is to fix your code so that
> it doesn't use the functions which are scheduled for deprecation.
> Improvements to the deprecated keyword have been in discussion to
> improve the situation. e.g.
> 
> https://github.com/D-Programming-Language/dmd/pull/345

What we could do in the meantime is to introduce the following at the top 
of the modules that uses the "soft deprecation" mechanism:

  version (NoSoftDeprecation) { } else version = SoftDeprecation;

Then, we could write the deprecation messages like this:

  version(SoftDeprecation) pragma(msg, "Notice: As of ...");

and people could silence the compiler with -version=NoSoftDeprecation.

Even better, we could define a mixin somewhere that includes the above, 
as well as a template containing a standardised deprecation message.  
That way, each module only needs to have something like this at the top:

  mixin (softDeprecationStuff!"std.path");

-Lars