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