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.



definitely a mess.

- Jonathan M Davis
Feb 06 2016