• Tomasz Sowiński (6/6) May 07 2009 This phrase gave me an idea for a small feat:
• Denis Koroskin (8/17) May 07 2009 It should rather have an optional boolean condition (and a string messag...
• Nick Sabalausky (22/30) May 07 2009 Deprication should not work like that. Deprication should be based on
• Georg Wrede (8/44) May 07 2009 Yes. It's a matter of principle, that a compiler should behave the same,...
• =?ISO-8859-1?Q?Tomasz_Sowi=f1ski?= (3/12) May 09 2009 I proposed this because, from my experience, no one would switch such a ...
• Jesse Phillips (6/19) May 08 2009 You should deprecate on the release it is deprecated and not before.
• =?ISO-8859-1?Q?Tomasz_Sowi=f1ski?= (5/31) May 09 2009 I wasn't really thinking about library releases from a vendor. In these,...
• Christopher Wright (3/13) May 10 2009 Put this in the control of the library creator. Have

Tomasz Sowi&#324;ski <tomeksowi.remove.this gmail.and.this.com> writes:

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

"Denis Koroskin" <2korden gmail.com> writes:

 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();

"Nick Sabalausky" <a a.a> writes:

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

Georg Wrede <georg.wrede iki.fi> writes:

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

=?ISO-8859-1?Q?Tomasz_Sowi=f1ski?= <tomeksowi.remove.this gmail.and.this.com> writes:

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

Jesse Phillips <jessekphillips gmail.com> writes:

 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.

=?ISO-8859-1?Q?Tomasz_Sowi=f1ski?= <tomeksowi.remove.this gmail.and.this.com> writes:

Nick Sabalausky Wrote:

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

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

Christopher Wright <dhasenan gmail.com> writes:

 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.