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.