Hmm - about manifest/enum

[Sean Kelly]

Sean Kelly wrote:
> Sean Kelly wrote:
>> Walter Bright wrote:
>>> Derek Parnell wrote:
>>>
>>>> The current decision to reuse 'enum' for manifest constants is yet 
>>>> another
>>>> example of a designer believing that their intuition is better than 
>>>> their
>>>> customers', regardless of any evidence to the contrary. Please 
>>>> reconsider
>>>> that there might be a remote possibility that this decision is actually
>>>> wrong in this case; 'enum' is not the best choice for developers 
>>>> when it
>>>> comes to declaring manifest constants.
>>>
>>> There are a number of people who strongly feel it is the correct 
>>> decision who are not vocal about it.
>>
>> I don't suppose the use of 'enum' in this context has had any impact 
>> on named enumerations?  ie. We still cannot have a named enum which 
>> contains strings, correct?  Also, are traditional unnamed enums still 
>> legal?
>>
>> enum
>> {
>>     a, b, c
>> }
>>
>> enum : long
>> {
>>     d, e, f
>> }
> 
> err... assume there are values assigned to the members above.

Seems it does still work that way.  It's not a big thing, but is perhaps 
worth mentioning that the new enum feature does change the behavior of 
existing code:

     enum
     {
         a = byte.max
     }

     void main( char[][] args )
     {
         printf( "%.*s: %d\n", typeid(typeof(a)).toString, a );
     }

Under D 1.0 this prints:

     int: 127

And under D 2.0 this prints:

     byte: 127

I can see this causing occasional rare problems for code transitioning 
to 2.0, but probably nothing serious.  Fortunately, this is disallowed 
in 1.0:

     enum { a = long.max }


Sean