On Friday, 11 April 2014 at 11:18:34 UTC, Jonathan M Davis wrote:
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
I agree with you here.
