PhobosWatch: manifest => enum

Steven Schveighoffer schveiguy at yahoo.com
Fri Dec 28 13:34:44 PST 2007


"Walter Bright" wrote
> Steven Schveighoffer wrote:
>> This is going to confuse the hell out of all newcomers, and I think there 
>> are very few people who use D that actually think this is a good idea 
>> (myself included).  There are much better ways to solve this problem than 
>> destroying the traditional meaning of enum.
>
> I understand your point, but also consider that adding yet a fourth way to 
> declare constants is not going to be illuminating for newcomers

This is worse.  You are now changing the meaning of enum as it was in C or 
C++.  So to a newcomer who knows what enum is, they will breeze through that 
section of the manual, thinking 'D has enums, cool, I already know how to 
use those' and be utterly confused when they come across an example like:

enum
{
   x = 1,
   y = "hello"
}

> it makes D look like a mishmash.

That's a very subjective statement.  I don't think it does.  I think 
multiple uses for the same keyword look messier than multiple keywords that 
mean distinct things.

> Furthermore, it does not destroy the meaning of enum. Already, you can do 
> this in C, C++ and D:
>
>   enum { x = 1, y = 2 }   // x and y are int's
>
> we just extend it a bit so that they don't have to be all the same type:
>
>   enum { x = 1, y = 2L }  // x is int, y is long

No, it's a redefinition.  Now enum does not mean enumeration, it means 
manifest constant.  Oh and by the way, if you assign a symbol name to an 
enum, it becomes a traditional enum (with a type and the requirement that 
all the values have the same type).  Having one keyword mean two different 
things, when used in slightly different ways is very very confusing.

Consider this:

enum Foo { x = 'a' }

Now we remove Foo:

enum { x = 'a' }

Now x is a char, where Foo.x was an int?  That is very confusing. 
Especially if you are reading a long list of constants, and can't remember 
whether the type was specified at the top or is specified by the rvalue.

Here's an analogy:

Imagine a language which did not have pointers.  But some clever coder 
figured out how to use ints as pointers.  And then the developer of the 
langauge says 'were going to support int as a pointer if you put a dot after 
it, because people already use ints as pointers anyways'

The example is simple, and probably unrealistic, but it captures the "oh my 
god, what is he thinking" reaction that I have to this change.

> We also drop the requirement that enum types be only integral ones.

This, I agree with and support.  It's the multiple types in one enum 
declaration that is really confusing, and the loosening of the definition 
that an enum is an enumeration of related values instead of a list of 
constants.

-Steve 





More information about the Digitalmars-d mailing list