SCHEDULED for deprecation

[Tomasz Sowiñski]

Nick Sabalausky Wrote:

> <Tomasz Sowiñ>; "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.

I wasn't really thinking about library releases from a vendor. In these, deprecation should be version-based, as you say, so this feature wouldn't be used.

I was thinking of cases where maintanance is often overlooked, say quick'n'dirty library modules -- there's no version, it's dumped into the same repository along with code referencing it. Often someone marks the previous API deprecated and but removing the code, getting collegaues to rewrite their code gets pushed in time forever, because there's always too little time to think about maintanance.

Having a fixed date enforced by the compiler is not really rude then, it improves communication (people know whether they should hurry, it's all in ddoc and warnings) and serves as a reminder, for both the programmer and the library writter. Plus, if someone wants to "snooze" the maintanance wake up call, at least they have to do it consciously.

Tomek