enum

Jonathan M Davis jmdavisProg at gmx.com
Fri Apr 11 04:18:10 PDT 2014


On Friday, April 11, 2014 00:05:21 Walter Bright wrote:
> On 4/10/2014 11:25 PM, Jonathan M Davis wrote:
> > Except that the only static type checking you're getting is protection
> > against direct assignment.
> 
> More than that. It's arguments to functions, and overloading.

Well, arguments to functions are essentially the same as direct assignment in 
the sense that the compiler is protecting against you explicitly giving a 
variable of an enum type a value that isn't one of its enumerated values, but 
I did definitely forget about overloading. Still, if the idea is that enums 
list only some of their possible values, what does overloading really buy you? 
Again, you have the problem that you have schizoid situation where the 
compiler is trying to treat the enum differently from its base type and yet 
its enumerated values are only supposed to be _some_ of its possible values, 
meaning that its other possible values require casts - and even worse, they 
require casts just for a few specific operations.

The protections against setting an enum variable to a non-enumerated value 
would seem to indicate that enum variables should only have one of the values 
which was explicitly enumerated by that enum type. Certainly, I don't see much 
point in having those protections if it's expected that an enum variable can 
have other values. The protections just make it harder to use those other 
values.

And if we're going to protect against setting a variable of an enum type to a 
non-enumerated value (be it via direct assignment or via a function argument), 
why not protect against _all_ operations which would result in an enum 
variable having a value which wasn't enumerated? What's so special about 
directly setting the variable versus other operations (e.g. arithmetic or 
concatenation)?

Also, both language features (e.g. final switch) and the standard library 
(e.g. std.conv.to) expect for a variable of an enum type to only have one of 
the enumerated values. So, code which uses other values for enums is likely to 
have serious problems.

And honestly, I don't see much point to enums if they're not intended to list 
all of their values. And I'm quite certain that the vast majority of D code 
using enums assumes that an enum variable is one of the enumerated values. It 
may very well be the case that there's D code out there that doesn't have that 
expectation, but Phobos does, and every discussion I've ever seen on it seems 
to. Your post suggesting that it's not necessarily intended that an enum 
variable only hold one of the enumerated values is the first time that I've 
ever seen anyone suggest that, and given how final switch works and the few 
protections we do have against giving an enum variable non-enumerated values, 
it certainly seems like the language is designed with the idea that all of the 
possible values of an enum be enumerated rather than expect that there could 
be others.

- Jonathan M Davis


More information about the Digitalmars-d mailing list