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

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

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

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

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.

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