On Wednesday, August 29, 2012 12:40:45 Manu wrote: > I've conceded that I don't mind changing my code, if a satisfactory > alternative exists (it doesn't currently). Also, I'd like to have some > notice that I need to make some time to change the code, and the > opportunity to work it into my schedule. > Surely that's not unreasonable.
Ideally, something which is going to be deprecated is first scheduled for deprecation (and marked as such in both the changelog and documentation) and then later deprecated, giving programmer's time to change their code first. It almost always works that way with druntime and Phobos, but I don't think that we necessarily do as good a job with the compiler. Frequently the situation is that people on the newsgroup know fullwell that a feature is going to be deprecated (e.g. delete), but that's not well communicated outside of this group, and for some reason, the to-be-deprecated items just don't get deprecated even though it's been definitively decided that they will be at some point. In this particular case, it was viewed as a bug fix, and bug fixes break code all the time (especially accepts-invalid bugs), so no effort was made to indicate that a feature was going away (i.e. it was viewed as feature being fixed rather than a feature going away, so no notification beyond the bugfix in the changelog was given). Obviously, this was not handled in the best way, as this thread has shown. But stuff that's actually viewed as being deprecated generally is handled much better. - Jonathan M Davis