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
