DIP 1013: The Deprecation Process -- Community Review Round 1

[Jonathan M Davis]

On Wednesday, April 18, 2018 12:48:18 Mike Franklin via Digitalmars-d wrote:
> On Wednesday, 18 April 2018 at 12:28:59 UTC, Jonathan M Davis
>
> wrote:
> >> > In order to facilitate on schedule deprecations, a comment
> >> > of the format @@@DEPRECATED_[version]@@@ should be added to
> >> > the top of the code to be removed/disabled.
> >>
> >> Is `[version]` the version in which the deprecation took
> >> place, or the future version in which the next stage is to
> >> take place. For example, if I'm deprecating a feature in
> >> 2.080, should `[version]` be 2.080, or 2.085 (the version in
> >> which the features is changed to an error)?
> >
> > As I said before, it's never changed to an error. The DIP quite
> > specifically never does that, and really I don't think that it
> > should.
>
> The current process, as I understand it for language features, is
> the deprecated feature is a deprecation message for a year, and
> then an error for a year.  After 2 years of being deprecated it
> is removed.  Perhaps you were only referring to a deprecated
> library feature.

I'm referring specifically to the library. As far as I can tell, the
language hasn't had a real process, and it's been handled differently
practically every time, so adding process would be an improvement. I think
that it's been very typical for anything that's been deprecated in the
language to stay that way for a long time. And I definitely don't think that
they've been anywhere near as organized as what you're suggesting (though
they may very well have gotten better about it recently). Either way, I
don't have strong feelings about how the language itself is handled, though
a similar length for the deprecation process makes sense.

Having it be an error for the language makes some sense, because it's not
necessarily the case that once it's gone, the code won't compile anymore
(depending on the feature being deprecated), but for the library, that would
just cause problems, and we don't really have a way to make it happen even
if we wanted to. It's going to be pretty rare that removing a symbol from
Phobos is going to result in code compiling that didn't compile while the
deprecated symbol was in place, and turning deprecation messages into errors
has the same effect as removing the symbol as far as code breakage goes.

If the compiler devs want to do something differently with the language
itself, I don't really care so long as it's reasonable. But I'm very
opinionated about what happens with the library, in part, because I'm
essentially the person in charge of managing deprecations there.

- Jonathan M Davis