Bug 11130 – Enum members are now all in scope when evaluating enum member initializers

Status
RESOLVED
Resolution
FIXED
Severity
enhancement
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2013-09-27T06:34:00Z
Last change time
2013-10-26T08:01:19Z
Keywords
spec
Assigned to
nobody
Creator
andrej.mitrovich

Comments

Comment #0 by andrej.mitrovich — 2013-09-27T06:34:40Z
This may or may not have been an intended change: ----- enum A = 1; enum E { A = A } void main() { } ----- $ dmd test.d test.d(7): Error: enum member test.E.A circular reference to enum member The workaround is simple for module-scoped enums, use the [dot] expression to look up module-scoped symbols: ----- enum A = 1; enum E { A = .A // works } void main() { } ----- However the following code does not have an easy workaround: ----- void main() { enum A = 1; enum E { // circular reference, cannot use ".A" here // because "A" is not in module scope A = A } } ----- Above you would likely have to introduce an alias such as: ----- void main() { enum A = 1; alias thisA = A; enum E { A = thisA // ok } } ----- If this regression was intended we're going to have to properly document it, both in the docs and in the upcoming changelog. The regression was found in DGui, where some enum members have the same name as WinAPI constants, but were purposefully wrapped in the enum to make the constants typed: enum EdgeType : uint { RAISED_OUTER = BDR_RAISEDOUTER, RAISED_INNER = BDR_RAISEDINNER, SUNKEN_OUTER = BDR_SUNKENOUTER, SUNKEN_INNER = BDR_SUNKENINNER, BUMP = EDGE_BUMP, ETCHED = EDGE_ETCHED, EDGE_RAISED = EDGE_RAISED, // issue here SUNKEN = EDGE_SUNKEN, }
Comment #1 by bugzilla — 2013-09-27T11:56:20Z
This was an intended change. Before, an enum member was not inserted into the symbol table until *after* its initialization expression was evaluated. But in order for forward references to work, this is no longer possible, now all the enum member symbols are visible inside the { }. I am surprised this broke any code, I don't consider it a reasonable practice, but you're right that we need to document this behavior. I'm going to reset this as a "spec" issue.
Comment #2 by bugzilla — 2013-09-28T15:36:09Z
Comment #3 by github-bugzilla — 2013-10-18T14:24:56Z
Commits pushed to master at https://github.com/D-Programming-Language/dlang.org https://github.com/D-Programming-Language/dlang.org/commit/9d451c948483ea1425a835841e70bcc20e76c7f6 fix Issue 11130 - Enum members are now all in scope when evaluating enum member initializers https://github.com/D-Programming-Language/dlang.org/commit/9ad3961dee2c6ea1710e3a1ba3391b993ab11985 Merge pull request #387 from WalterBright/fix11130 fix Issue 11130 - Enum members are now all in scope when evaluating enum...
Comment #4 by github-bugzilla — 2013-10-26T08:01:19Z
Commit pushed to 2.064 at https://github.com/D-Programming-Language/dlang.org https://github.com/D-Programming-Language/dlang.org/commit/5572a0c432418a36fe3216fd076b84751628c97b Merge pull request #387 from WalterBright/fix11130 fix Issue 11130 - Enum members are now all in scope when evaluating enum...