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
