Deprecations: Any reason left for warning stage?

[Vladimir Panteleev via Digitalmars-d]

On Monday, 29 September 2014 at 10:15:07 UTC, David Nadlinger 
wrote:
> On Friday, 26 September 2014 at 18:38:43 UTC, Steven 
> Schveighoffer wrote:
>> Case against: 
>> https://github.com/D-Programming-Language/phobos/pull/2254#issuecomment-52764718
>
> I don't think this is relevant for this discussion at all. 
> Vladimir asked for advance notice in terms of docs before 
> anything changes about the actual implementation. Making stuff 
> a Warning addresses this just as much or as little as making it 
> a Deprecation does.

To clarify, what I'm really asking is a one-release-window in 
which both the old and new way to do something works without any 
warnings or deprecated messages. This is so I'm not forced to 
update the compilers or all my machines simultaneously. This is 
especially important considering LDC/GDC usually lag one frontend 
version behind: if you use bleeding-edge DMD for development, you 
can't enable all the deprecation/warning messages (which should 
be enabled during development of new code) without either 
breaking GDC/LDC/DMD v. N-1 compatibility, or dealing with the 
spam.

How the change is reflected in the documentation (kept, scheduled 
for deprecation, or removed), is not very important to me 
personally.

> To put it differently: Were the issue in question a language 
> change (under the current deprecation process), Vladimir would 
> have complained all the same about DMD spewing Warning messages.

All's good as long as there exists syntax that is silently 
accepted in both version N and N+1.

> You might even be able to construe it as an argument in favor 
> of dropping the Warning stage – at least deprecation warnings 
> can easily be filtered out without hiding potentially useful 
> Warnings that might indicate something wrong with your code.

This would be more applicable if deprecation messages included a 
version number indicating when a certain feature was deprecated.