Fun with range deprecations
Jonathan M Davis via Digitalmars-d
digitalmars-d at puremagic.com
Mon Aug 11 20:10:29 PDT 2014
On Tuesday, 12 August 2014 at 00:47:20 UTC, ketmar via
Digitalmars-d wrote:
> On Tue, 12 Aug 2014 00:18:26 +0000
> Meta via Digitalmars-d <digitalmars-d at puremagic.com> wrote:
>
>> What about modifying is(typeof(...)) to return false for
>> deprecated symbols?
> btw, we can add 'date' arg do deprecated(), so compiler will
> spit
> warnings before that date and rejects deprecated code after
> this date.
>
> this gives us another fine thing: forgotten deprecations, which
> was
> sheduled but their shedule date missed, will immediately break
> unfixed
> code.
>
> i'm pretty sure that such enhancement was proposed before and
> rejected
> for good reasons, but i cannot into search (as always).
Release numbers might make sense (at least for the standard
library; it wouldn't for normal code, since it wouldn't be tied
to compiler releases), but dates don't make any sense at all when
you consider maintenance. If I'm writing a program today, and it
compiles with dmd 2.065, and I have to come back and work on it
two years from now, it should still compile exactly the same with
2.065. Sure, it may not compile with the current compiler at the
time, but builds can't suddenly start failing because of a date
change. In production environments, it's freuently the case that
specific compiler and library versions are used and not freuently
updated, and those builds have to continue to work. So,
compiler-enforced date-based deprecation doesn't make any sense.
But regardless of whether it would have made sense, Walter was
adamantly opposed to pretty much anything which complicated the
deprecated feature, so all proposals which were more complex than
what we currently have were shot down. But for the most part,
what we have is plenty. Making it so that deprecation messages
were just informational rather than stopping compilation and
making it possible to add user-defined informational messages to
deprecated were huge steps forward as it was. While what we have
isn't perfect, it does work most of the time. But deprecating
stuff is always a messy business, so I suppose that it's not
completely surprising that we're running into issues like this.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list