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