www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Deprecation policy

reply Marc =?UTF-8?B?U2Now7x0eg==?= <schuetzm gmx.net> writes:
Can someone point me to our current deprecation policy?

The "Deprecated Features" page [1] lists some features that we 
already warn about for some time, that could probably be moved 
forward. `.sort/.reverse` in particular is something we should 
get rid of better sooner than later.

[1] http://dlang.org/deprecate.html
Feb 02 2016
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, 2 February 2016 at 14:05:05 UTC, Marc Schütz wrote:
 Can someone point me to our current deprecation policy?

 The "Deprecated Features" page [1] lists some features that we 
 already warn about for some time, that could probably be moved 
 forward. `.sort/.reverse` in particular is something we should 
 get rid of better sooner than later.

 [1] http://dlang.org/deprecate.html
With regards to language features, we really don't have a policy. Some stuff has been in the state of "we're definitely going to deprecate it" for ages (e.g. delete and using scope on local variables) but never actually gets deprecated, and other stuff gets deprecated but doesn't get removed for ages. And I think that it mostly comes down to when a compiler dev feels like making the change (and they usually don't - probably because they have much more interesting and pressing things to worry about). The situation with deprecations in the standard library is generally much better, but that's because I manage it and mostly keep on top of it (though occasionally, I've missed something, and it's sat around for way too long). AFAIK, none of the compiler devs really want to be the one to make sure that deprecations in the compiler get moved along (especially since it's generally more complicated than using the deprecated attribute). So, it happens whenever someone happens to feel like doing it rather than on any kind of schedule. Now, in this particular case, you're talking about features that were warned about starting in 2.067, which was released at the end of March of last year. Removing them now would be awfully quick. The deprecation cycle in Phobos is two years long so that folks have plenty of chance to update their code, and older code that's not well maintained has some chance of compiling when it is finally brought up to date. So, I'm inclined to think that it's way too early to remove .sort or .reverse from the language. Of greater concern to me are the features that we never actually deprecate even though we're sure that we want to (e.g. delete), because that just means that more and more code gets written which uses it without getting a deprecation message or a warning to indicate that the code should not be written that way. - Jonathan M Davis
Feb 03 2016
next sibling parent reply Marc =?UTF-8?B?U2Now7x0eg==?= <schuetzm gmx.net> writes:
On Wednesday, 3 February 2016 at 19:25:20 UTC, Jonathan M Davis 
wrote:
 Now, in this particular case, you're talking about features 
 that were warned about starting in 2.067, which was released at 
 the end of March of last year. Removing them now would be 
 awfully quick. The deprecation cycle in Phobos is two years 
 long so that folks have plenty of chance to update their code, 
 and older code that's not well maintained has some chance of 
 compiling when it is finally brought up to date. So, I'm 
 inclined to think that it's way too early to remove .sort or 
 .reverse from the language.
Sure, I'm not suggesting to remove them yet, but they need to get through all stages first, and any delay will push the date we can finally get rid of them further back. The next stage is "deprecated". Would that be ok now? Btw, this is the PR that caused my question: https://github.com/D-Programming-Language/dlang.org/pull/1205
Feb 04 2016
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, 4 February 2016 at 11:29:59 UTC, Marc Schütz wrote:
 On Wednesday, 3 February 2016 at 19:25:20 UTC, Jonathan M Davis 
 wrote:
 Now, in this particular case, you're talking about features 
 that were warned about starting in 2.067, which was released 
 at the end of March of last year. Removing them now would be 
 awfully quick. The deprecation cycle in Phobos is two years 
 long so that folks have plenty of chance to update their code, 
 and older code that's not well maintained has some chance of 
 compiling when it is finally brought up to date. So, I'm 
 inclined to think that it's way too early to remove .sort or 
 .reverse from the language.
Sure, I'm not suggesting to remove them yet, but they need to get through all stages first, and any delay will push the date we can finally get rid of them further back. The next stage is "deprecated". Would that be ok now? Btw, this is the PR that caused my question: https://github.com/D-Programming-Language/dlang.org/pull/1205
Well, warning and deprecated aren't exactly in a continuum. If something is a warning, then it fails to compile with -w, whereas if it's deprecated, it'll always compile but will print out a message unless -d is used. And much as the table seems to claim that most stuff went from deprecated to error, I'm pretty sure that several of them went from warning to error. So, I don't think that there's exactly a clear progression of stages here. Regardless, I see no problem with making using .sort or .reverse result in a deprecation message in addition to it being a warning (removing the warning would make code that didn't compile before start compiling and affect compile-time introspection). Not everyone builds with warnings turned on, whereas everyone would see the deprecation messages, so more people would notice if it were also explicitly deprecated. But we can't make it an error or remove it for a while yet IMHO. - Jonathan M Davis
Feb 04 2016
prev sibling parent reply Daniel Murphy <yebbliesnospam gmail.com> writes:
On 4/02/2016 6:25 AM, Jonathan M Davis wrote:
 With regards to language features, we really don't have a policy. Some
 stuff has been in the state of "we're definitely going to deprecate it"
 for ages (e.g. delete and using scope on local variables) but never
 actually gets deprecated, and other stuff gets deprecated but doesn't
 get removed for ages. And I think that it mostly comes down to when a
 compiler dev feels like making the change (and they usually don't -
 probably because they have much more interesting and pressing things to
 worry about).
There are other things holding up deprecated features other than lack of time/energy. - Walter/Andrei have declared features deprecated for ideological reasons, yet they're still useful and don't have good alternatives. - Walter/Andrei have refused or extended reasonable deprecation paths because they will break code So implementing a deprecation typically means five minutes of writing a compiler patch, an hour of removing ancient uses from obscure druntime code, 12 months of waiting for review and 3 weeks of arguing with Walter and/or Andrei and/or anyone else who can't be bothered updating their code. See https://issues.dlang.org/show_bug.cgi?id=4733 for why I don't bother any more.
Feb 05 2016
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, 5 February 2016 at 11:11:40 UTC, Daniel Murphy wrote:
 There are other things holding up deprecated features other 
 than lack of time/energy.

 - Walter/Andrei have declared features deprecated for 
 ideological reasons, yet they're still useful and don't have 
 good alternatives.
 - Walter/Andrei have refused or extended reasonable deprecation 
 paths because they will break code

 So implementing a deprecation typically means five minutes of 
 writing a compiler patch, an hour of removing ancient uses from 
 obscure druntime code, 12 months of waiting for review and 3 
 weeks of arguing with Walter and/or Andrei and/or anyone else 
 who can't be bothered updating their code.

 See https://issues.dlang.org/show_bug.cgi?id=4733 for why I 
 don't bother any more.
Yeah. I can definitely understand that. And issue# 4733 was definitely a mess. - Jonathan M Davis
Feb 06 2016