I've resurrected a PR that fixes an implementation bug.  https://github.com/dlang/dmd/pull/7332

The existing implementation does not comply with the spec.  The PR fixes that, but it may cause breakage, so in the original PR, there was a preference to have it go through the deprecation process.

The deprecation process documented at https://dlang.org/deprecate.html#Imaginary%20and%20complex%20types gives the following procedure (kindof).


Spec - Removal from the Specification
Dep - The compiler warns by default, issues an error with the -de switch, and can be silenced with the -d switch
Error - It is an error to use the feature
Gone - The feature is completely gone

While I'm sure there are exceptions, *typically* for how long, or how many releases, is the Deprecation warning to remain in place before the Error is released?  Also, for how long, or how many releases, is the Error to remain in place before the feature is removed?  Is that currently documented anywhere?

Thanks,
Mike

On Saturday, November 18, 2017 23:12:45 Michael V. Franklin via Digitalmars- d wrote:
> I've resurrected a PR that fixes an implementation bug. https://github.com/dlang/dmd/pull/7332
>
> The existing implementation does not comply with the spec.  The PR fixes that, but it may cause breakage, so in the original PR, there was a preference to have it go through the deprecation process.
>
> The deprecation process documented at https://dlang.org/deprecate.html#Imaginary%20and%20complex%20types gives the following procedure (kindof).
>
>
> Spec - Removal from the Specification
> Dep - The compiler warns by default, issues an error with the -de
> switch, and can be silenced with the -d switch
> Error - It is an error to use the feature
> Gone - The feature is completely gone
>
> While I'm sure there are exceptions, *typically* for how long, or how many releases, is the Deprecation warning to remain in place before the Error is released?  Also, for how long, or how many releases, is the Error to remain in place before the feature is removed?  Is that currently documented anywhere?

If we're talking about deprecations in the language, they're done so infrequently and inconsistently that I don't think that much could really be said about how long any of the process is. Moving anything through any point of the process generally seems to be done based on when someone feels like it, generally with it being quite a while for each stage. Maybe the compiler devs have more of a process for it than I think they do, but from everything I've seen, stuff just tends to sit in whatever stage it's in and rarely gets moved along.

For deprecations in the library, symbols are typically deprecated and documented for a year and then deprecated and undocumented for a year, and then they're removed. It's not applied completely consistently, but that's the policy, and it's generally more or less followed. However, it's followed as well as it is mostly because I shepherd the process, and AFAIK, no one really does that for the compiler - but deprecations in the language are also far rarer than they are in Phobos.

- Jonathan M Davis