On 2011-10-02 05:24:36 +0000, Jonathan M Davis <[email protected]> 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 errorThe 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 [email protected] http://michelf.com/
