non-integral enums?
Chris Sauls
ibisbasenji at gmail.com
Fri Feb 24 17:49:29 PST 2006
Tom wrote:
> In article <t194d3-6dn.ln1 at birke.kuehne.cn>, Thomas Kuehne says...
>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>Is there any reason why enum-base-types are restricted to integers?
>>
>>How about lifting the integer restriction and updating the documentaion:
>>
>>http://digitalmars.com/d/enum.html (DMD-0.147)
>>
>>> If an Expression is supplied for an enum member, the value of the
>>> member is set to the result of the Expression. The Expression must be
>>> resolvable at compile time. Subsequent enum members with no
>>> Expression are set to the value of the previous member plus one
>>
>>new version:
>>
>>> If an Expression is supplied for an enum member, the value of the
>>> member is set to the result of the Expression. The Expression must be
>>> resolvable at compile time. If EnumBaseType is a numerical type,
>>> subsequent enum members with no Expression are set to the value of
>>> the previous member plus one.
>>
>>
>>http://digitalmars.com/d/enum.html (DMD-0.147)
>>
>>> Named enum members can be implicitly cast to integral types, but
>>> integral types cannot be implicitly cast to an enum type.
>>
>>new version:
>>
>>> Named enum members can be implicitly cast to their EnumBaseType, but
>>> the EnumBaseType cannot be implicitly cast to an enum type.
>>
>>Consequences:
>>
>>1) no changes for existing code
>>
>>2) enables float enums
>>
>># enum SpeedLimit : double
>># {
>># SLOW = 6.1,
>># FAST = 9.3
>># }
>>
>>3) enables struct enums
>>
>># struct S
>># {
>># int i;
>># float f;
>># }
>>#
>># enum E : S
>># {
>># A = { i:1, f:2.2},
>># B = { i:1, f:3.2},
>># C = { i:0, f:3.2}
>># }
>
>
> Don't you forget string enums. That would also be NICE!
>
> Tom;
A-bleeping-men.
-- Chris Nicholson-Sauls
More information about the Digitalmars-d
mailing list