dmd 1.069 and 2.054 release

[Michel Fortin]

On 2011-07-11 17:26:15 -0400, Andrew Wiley <wiley.andrew.j at gmail.com> said:

> To paraphrase your description, there's something that's about to break in
> your code, but it's not broken yet, so if you drop -w (or switch to -wi),
> you can still build it. If we're taking the approach that warnings break
> code when -w is used, I see scheduled deprecations falling into a very
> similar category.

To paraphrase your paraphrase, there's something that's about to break 
in your code, but it's not broken yet so if you add -d you can still 
build it... I'm simply side-stepping that discussion about 
implementation to illustrate that you just described the purpose of the 
'deprecated' keyword.

Personally, I think adding warnings or even messages for each and every 
scheduled-for-deprecation function is too much. Just adding it to the 
documentation and adding a note in the changelog should be enough. 
Then, one day, it'll be deprecated for real and you'll get an error 
unless you use -d.

I think one deprecation level is enough. The scheduled for deprecation 
step is still useful so that early adopters can try the new way to do 
things and report problems. Once it's been stable and adopted by some 
people you can ask for mass adoption by adding a deprecation message. 
But nagging users when they're using something that is scheduled for 
deprecation is pretty much the same as having the feature deprecated 
immediately in my view.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/