Proposal on improvement to deprecated

[Michel Fortin]

On 2011-10-02 05:24:36 +0000, Jonathan M Davis <jmdavisProg at gmx.com> said:

> deprecated("message", soft) void func1() {}
> deprecated("message", hard) void func2() {}

This soft/hard thing is a little obscure, no one will understand what 
it means by looking a it. Why not have separated 'deprecated' and 
'unavailable' states?

Also, the message part should be part of the Deprecated ddoc section in 
the documentation. Since the compiler knows about ddoc, wouldn't it be 
better if it could just write out the Deprecated ddoc section in the 
error message? This way they can't become out of sync.


> The way that Phobos will then deal with depreaction is as follows:
> 
> 1. A symbol which is going to be removed will be scheduled for deprecation.
> This means that its documentation will mark it as scheduled for deprecation,
> and it will be noted in the changelog that it has been scheduled for
> deprecation. But there will be _no_ compiler messages of any kind about the
> change. So, it's up to the programmer to pay attention and notice if anything
> has been scheduled for deprecation.

I'm not against that. But I think many people (including Walter) want 
to be notified by the compiler before it becomes an error. Passing 
straight from 'look at documentation' to 'compilation error' is too big 
of a step.

 - - -

In all this, my opinion is that 'deprecated' should be changed to emit 
informational messages (not errors) by default. Then you have this:

1. scheduled for deprecation: documentation only
2. deprecated: informational message
3. unavailable: compilation error

The scheduled for deprecation step would be mostly for things we know 
will be deprecated but that have no suitable replacement at the moment.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/