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