Comment #0 by andrej.mitrovich — 2013-01-25T17:48:41Z
Let's say you have an existing enum in your library API:
enum SpanMode
{
depth,
breadth,
shallow,
}
At some point you may decide you want to rename some of the members, but want to avoid code breakage for at least some time. You could introduce additional members which have the same values as the old ones:
enum SpanMode
{
deep, // new
wide, // new
shallow,
depth = deep, // old
breadth = wide, // old
}
This will work with switches, final switches, to!string, etc (although code that depends on EnumMembers!E.length could potentially break depending on what it does).
Don't mind the naming choice (it's just an example), but it would be useful to allow a deprecated statement in there, ala:
enum SpanMode
{
deep,
wide,
shallow,
deprecated("Please use SpanMode.deep")
depth = deep,
deprecated("Please use SpanMode.wide")
breadth = wide,
}
Comment #1 by andrej.mitrovich — 2013-06-15T08:00:30Z
*** Issue 10362 has been marked as a duplicate of this issue. ***
Comment #2 by issues.dlang — 2017-02-20T19:23:57Z
This would definitely be nice. I ran into this problem when working on bindings for Qt5. They have a number of enum members that they have added new names for and then marked the old ones as deprecated, and while most declarations in D can be marked as deprecated, the best that we can do here is say something in the documentation. Now, that's all that Qt can do either, since it's C++, but since pretty much any other declaration could be marked as deprecated in D, this restriction is annoying and arguably inconsistent.