Deprecated Library Functions / Methods

[Jonathan M Davis]

On Friday, November 30, 2012 16:04:01 Chris wrote:
> Is there a way of telling when things in the library will calm
> down and it'll be save to develop in D and update old code?
> 
> I started with D2 version 2.051 and created a medium-sized
> project fairly quickly, but now I have a lot of deprecated
> methods in my code. I couldn't keep up with all the changes and I
> have been hesitant to update my code because there are still a
> lot of "Will be removed in September/November/December ..."
> warnings in the library. Much that I like D, I simply cannot
> develop in D at the moment due to the constant changes in the
> Phobos library. I have this sinking feeling that this is killing
> the language.

A lot of changes were being done for a while to try and rename stuff to the 
follow the correct naming scheme and make other needed adjustments. That has 
dropped off considerably however and the goal is to make deprecations rare. 
It's just that there were a lot of changes that needed to be made to clean up 
the library. Most of that has been done has been done now, and the remainder 
is likely to just not be cleaned up or to stick around long term with an 
alternative which has been cleaned up. We don't want a lot of churn in the 
standard library. We want it to be stable so that people can rely on their 
code continuing to compile.

At present, there should be very little which is currently scheduled for 
deprecation, and it's unknown how long the stuff which has been actually 
deprecated will stay around. We were removing after 6 months of deprecation 
but have been re-examining that.

What we're trying to get Walter to do is to make it so that deprecated just 
generates warnings, not errors (rather a new flag will be added to make them 
generate errors if that's what you want, and -d will stay the same). With 
that, anything that gets deprecated should stick around for quite a while 
(though there's a good chance that it'll end up being undocumented after a 
while in order to further discourage its use), and it won't actually prevent 
compilation, just bug you to update your code. But as deprecations should 
become much rarer, even that won't happen anywhere near as often. There's an 
open pull request to make the change, but Walter hasn't agreed to it yet:

https://github.com/D-Programming-Language/dmd/pull/1287

I'd very much like to see the large blocks of stuff that was renamed or moved 
fully removed rather than sticking around as deprecated (e.g. std.ctype and 
all of the deprecated functions in std.string should go away), but we do want 
to be moving away from making large breaking changes like that, and 
deprecations should become quite rare. Pretty much all of those kind of 
changes which have been suggested recently have been rejected.

- Jonathan m Davis