SCHEDULED for deprecation
Nick Sabalausky
a at a.a
Thu May 7 12:29:31 PDT 2009
<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.
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).
More information about the Digitalmars-d
mailing list