Deprecations: Any reason left for warning stage?

[H. S. Teoh via Digitalmars-d]

On Fri, Sep 26, 2014 at 04:15:40PM +0000, David Nadlinger via Digitalmars-d wrote:
> As Walter mentioned in a recent pull request discussion [1], the first
> formal deprecation protocol we came up with for language changes
> looked something like this:
> 
> 1. remove from documentation
> 2. warning
> 3. deprecation
> 4. error
> 
> (The "remove from documentation" step is a bit questionable, but
> that's not my point here.)
> 
> However, in the meantime deprecations were changed to be informational
> by default. You now need to explicitly need to pass -de to turn them
> into errors that halt compilation. Thus, I think we should simply get
> rid of the warning step, just like we (de facto) eliminated the
> "scheduled for deprecation" stage from the Phobos process.
> 
> Thoughts?
[...]

I think the warning stage is still necessary. Users need to be informed
well ahead of time that something is going to be deprecated, before it
starts breaking their builds (which, according to recommended usage,
shouldn't be compiling with -d). We'll get a lot fewer angry users this
way.

Recently there was a case of a deprecation that broke the default build
of a large project, and the author was surprised (and not very happy) to
learn that something had been "suddenly" deprecated -- because the
deprecation warnings wouldn't even show up unless you specifically
compile with -dw. I think now -dw has been made default, which is the
right step forwards IMO, so it should be kept that way.


T

-- 
I'm still trying to find a pun for "punishment"...