enum

[Paulo Pinto]

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.