Jonathan M Davis <> changed:

           What    |Removed                     |Added
                 CC|                            |

--- Comment #1 from Jonathan M Davis <> 2011-01-24 08:09:34 
PST ---
A related feature would be to be able to have "soft" vs "hard" deprecation, so
that you can mark a symbol as scheduled for deprecation (so, the programmer is
notified like you get with the pragma messages now - though preferably with
something more like what's being suggested here with deprecated) without fully
deprecating it yet. Then you make it full deprecated and -d becomes required
for compilation to succeed (in addition to giving the programmer the message
about what they should be using instead).

Right now, the best we have is the ill-suited pragma messages for indicating
"scheduled for deprecation." And then we're stuck changing them (to indicate
deprecated rather than scheduled for deprecation) and keeping them around on
top of marking something as deprecated so that they'll tell the programmer what
to use now that the symbol in question has been deprecated.

So, I'm not sure what the best syntax is, but doing something like adding an
enum indicating Soft or Hard deprecation which could be fed to deprecated along
with the message would be ideal. e.g.

deprecated("Use newStuff instead.", Soft);
deprecated("Use newStuff instead.", Hard);

Presumably, Hard would be the default, as that how deprecated currently works.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to