https://issues.dlang.org/show_bug.cgi?id=14269
Steven Schveighoffer <schvei...@yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |schvei...@yahoo.com --- Comment #9 from Steven Schveighoffer <schvei...@yahoo.com> --- So if we examine why we don't allow ref to implicitly convert, it mostly has to do with preventing one from replacing the data referred to with a value that's valid for the base type, but invalid for the derived type. This is especially important for classes and pointers, because the pointer means completely different things as a base or derived type. However, we have somewhat of a unique situation with enum: 1. An enum is GUARANTEED to be the same size as it's "base" type, and have the same representation. 2. An enum is GUARANTEED to behave exactly the same way in terms of operators as its base type. 3. An enum is frequently used as a simple typedef, allowing one to define a new type of "int" e.g. with extra static values. I think you can make cases either way. The deprecation of typedef has kind of forced people into using enum as a "poor man's typedef". But clearly, there is no inherent danger in allowing ref of base type to bind to an enum, as the compiler already cannot make any assumptions about enums that are different from the base type. I would tend to say we should revert the restriction, even though I see and somewhat agree with the reasoning behind it. It seems inconsistent to say "We allow you to do enumvar |= somelong" and still type it as the enum, but we can't allow you arbitrary access via long. I would love to see a mechanism to allow enums to be further classified. In other words, what is allowed with this enum type? How is it intended to be used? This would give more clarity to how enum types are supposed to be used, and how the compiler can restrict usage. --