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?

Tomek

On Thu, 07 May 2009 20:57:36 +0400, Tomasz <Sowi&#324> wrote:

> 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?
>
> Tomek

It should rather have an optional boolean condition (and a string message):

version = ReplacementIntroduced;

deprecated(ReplacementIntroduced, "Use foo2() instead") // optional message
void foo();

Here is another example:

deprecated(__DATE__ > toDate!("2008-04-19"))
void foo();

<Tomasz Sowi&#324>; "ski" <tomeksowi.remove.this@gmail.and.this.com> wrote in message news:gtv3u0$2q00$1@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).

Nick Sabalausky wrote:
> <Tomasz Sowi&#324>; "ski" <tomeksowi.remove.this@gmail.and.this.com> wrote in message news:gtv3u0$2q00$1@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.

On Thu, 07 May 2009 12:57:36 -0400, Tomasz Sowiński wrote:

> 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?
> 
> Tomek

You should deprecate on the release it is deprecated and not before. However, providing a version for which the function would be removed entirely... And stating the alternative might also be nice.

Though these things could be placed in proper documentation, it is nice to have them readily available when you are told it is deprecated.

Georg Wrede Wrote:

> 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.
> 

I proposed this because, from my experience, no one would switch such a switch. Time-pressure erradicates all thoughts about maintanance, as long as it works/compiles.

Tomek

Tomasz Sowiński wrote:
> 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?
> 
> Tomek

Put this in the control of the library creator. Have scheduled_for_deprecation and deprecated.