SCHEDULED for deprecation

[Georg Wrede]

Nick Sabalausky wrote:
> <Tomasz Sowi&#324>; "ski" <tomeksowi.remove.this at gmail.and.this.com> wrote 
> in message news:gtv3u0$2q00$1 at digitalmars.com...
>> This phrase gave me an idea for a small feat:
>>
>> deprecated(2009-4-19) void foo();
>>
>> Compiling references to the deprecated declaration *before* the 
>> deprecation date would result in a *warning*.
>> Compiling the deprecated declaration OR any reference to it *after* the 
>> date would result in an *error*.
>>
>> Advantages for maintanance are obvious, plus, the feature seems easy to 
>> implement. What do you think?
>>
> 
> Deprication should not work like that. Deprication should be based on 
> versions, not actual dates. Basing it on dates like that can cause a number 
> of different problems for, and can even be considered disrespectful to, your 
> API's users. If/when you reach a point where you decide it's time for 
> something to be depricated, you should put out a new release. Even if you 
> have a way to know for certain that release will actually occur on-time, 
> then there would clearly be no problem in just waiting until that point to 
> put out a release that depricates the old stuff. Plus, that way you're not 
> rudely attempting to force the hand of your API user. If they're ok with 
> something being depricated, then they can upgrade to the newest version at 
> their own will, whevever *they* decide it's time for *them* to do so.
> 
> As far as the idea of "deprication warning and then later a deprication 
> error", we already have something that's...almost...just as good: If you get 
> a deprication error but you're not yet ready to convert, there's a compiler 
> switch to allow depricated stuff. However, I say "*almost* as good" because 
> thanks to DMD's complete inability to treat warnings AS warnings (instead of 
> always insisting on treating them as errors, 
> http://d.puremagic.com/issues/show_bug.cgi?id=2567 ) it's impossible to get 
> a complete list of depricated references in a program (and even that would 
> only happen if deprications were able to be considered warnings at all).

Yes. It's a matter of principle, that a compiler should behave the same, 
no matter what the wall clock says. (Commercial beta versions excluded, 
which totally stop working at a fixed date, but that's different.)

What could be useful is a switch --show-deprecated that simply puts out 
a list of the currently deprecated functions and things. But that's 
asking for too much, I admit. Rather, the change log would be the right 
place for that. There they should be in one place, diligently listed.