enum

Jonathan M Davis jmdavisProg at gmx.com
Sat Apr 12 06:06:04 PDT 2014


On Saturday, April 12, 2014 07:25:34 deadalnix wrote:
> There is no point in introducing additional core language
> feature, simply sanitize what exists and extends library support
> for uses cases discussed in this thread.

Simply making it so that any operation (other than casting) on a variable of 
an enum type which isn't guaranteed to result in one of that enum's enumerated 
values results in the base type rather than the enum type would fix the 
problem. final switch would work great at that point. The other use cases 
could then easily be done via aliases or structs or some other library 
solution. But as it stands, enums are not protected well enough to guarantee 
that they're not going to have invalid values (thereby screwing up stuff like 
final switch), and the little protection that they do provide (you can't 
initialize them or assign to them non-enumerated values) just gets in the way 
of the other use cases. What we have is stuck halfway in between, which is 
just plain bad IMHO.

We should either fix it so that enum types are protected by the compiler 
against having non-enumerated values, or remove the restrictions on them and 
just treat enum types as aliases. What we have now doesn't properly serve any 
of the use cases.

- Jonathan M Davis


More information about the Digitalmars-d mailing list