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