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}
# }

Thomas

In article <t194d3-6dn.ln1@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;

Tom wrote:
> In article <t194d3-6dn.ln1@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

Thomas Kuehne wrote:
> -----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}
> # }
> 
> Thomas
> 
> 
> -----BEGIN PGP SIGNATURE-----
> 
> iD8DBQFD/3UA3w+/yD4P9tIRAvbrAKCRJVzOd8tgfu3yUJqoy7spILy9XgCfbq/q
> 9pwmXsSd/EhVdNJsoNN1tOc=
> =LEQd
> -----END PGP SIGNATURE-----


How different is enum from constants then?

On Sat, 25 Feb 2006 13:12:10 +1100, Wang Zhen <nehzgnaw@gmail.com> wrote:



[snip]

> How different is enum from constants then?

I agree. I thought enum were invented as a shorthand way of doing ...

  const int red = 1,
            blue = 2,
            green = 3;

Instead we can do 'enum colors { red, blue, green }'

To saving the coder having to recalculate the 'enumerated' names when some were added or deleted.

  const int red = 1,
            yellow = 2,
            blue = 3,
            green = 4;

Instead we can do 'enum colors { red, yellow, blue, green }'

Otherwise they are just constants of varying values.

-- 
Derek Parnell
Melbourne, Australia

Actually, isn't it more like a typedef (but not completely) and a namespace?

In that case, you can do colors.red - you have to do this right now if you want to use constants: (iirc)

static struct colors
{
   const int red = 1;
}

But then it is an int, and implicit casting is not as described by Thomas Kuehne.

-[Unknown]


> On Sat, 25 Feb 2006 13:12:10 +1100, Wang Zhen <nehzgnaw@gmail.com> wrote:
> 
> 
> 
> [snip]
> 
>> How different is enum from constants then?
> 
> I agree. I thought enum were invented as a shorthand way of doing ...
> 
>   const int red = 1,
>             blue = 2,
>             green = 3;
> 
> Instead we can do 'enum colors { red, blue, green }'
> 
> To saving the coder having to recalculate the 'enumerated' names when some were added or deleted.
> 
>   const int red = 1,
>             yellow = 2,
>             blue = 3,
>             green = 4;
> 
> Instead we can do 'enum colors { red, yellow, blue, green }'
> 
> Otherwise they are just constants of varying values.
> 
> --Derek Parnell
> Melbourne, Australia

Actually any enum without an identifier just introduces constants into the current scope, as per the previously cited examples.  So in essence, an enum is just a collection of constants (of identical type) and an optional namespace to contain them, and a special rule that enum namespaces can be used as types.

-- Chris Nicholson-Sauls

Unknown W. Brackets wrote:
> Actually, isn't it more like a typedef (but not completely) and a namespace?
> 
> In that case, you can do colors.red - you have to do this right now if you want to use constants: (iirc)
> 
> static struct colors
> {
>    const int red = 1;
> }
> 
> But then it is an int, and implicit casting is not as described by Thomas Kuehne.
> 
> -[Unknown]
> 
> 
>> On Sat, 25 Feb 2006 13:12:10 +1100, Wang Zhen <nehzgnaw@gmail.com> wrote:
>>
>>
>>
>> [snip]
>>
>>> How different is enum from constants then?
>>
>>
>> I agree. I thought enum were invented as a shorthand way of doing ...
>>
>>   const int red = 1,
>>             blue = 2,
>>             green = 3;
>>
>> Instead we can do 'enum colors { red, blue, green }'
>>
>> To saving the coder having to recalculate the 'enumerated' names when some were added or deleted.
>>
>>   const int red = 1,
>>             yellow = 2,
>>             blue = 3,
>>             green = 4;
>>
>> Instead we can do 'enum colors { red, yellow, blue, green }'
>>
>> Otherwise they are just constants of varying values.
>>
>> --Derek Parnell
>> Melbourne, Australia

Exactly.  But there's also that tiny last bit of your last sentence.  In other words, this does not compile:

enum X
{
	Y
}

int main()
{
	int i;
	X x;

	x = i;

	return 0;
}

But this does:

static struct X
{
	const int Y = 1;
}

int main()
{
	int i;
	typeof(X.Y) x;

	x = i;

	return 0;
}

You are very correct that this is just about the only difference between enums and namespaced constants.  But this is, in my mind, a desirable difference, as much as you may marginalize it.

-[Unknown]


> Actually any enum without an identifier just introduces constants into the current scope, as per the previously cited examples.  So in essence, an enum is just a collection of constants (of identical type) and an optional namespace to contain them, and a special rule that enum namespaces can be used as types.
> 
> -- Chris Nicholson-Sauls
> 
> Unknown W. Brackets wrote:
>> Actually, isn't it more like a typedef (but not completely) and a namespace?
>>
>> In that case, you can do colors.red - you have to do this right now if you want to use constants: (iirc)
>>
>> static struct colors
>> {
>>    const int red = 1;
>> }
>>
>> But then it is an int, and implicit casting is not as described by Thomas Kuehne.
>>
>> -[Unknown]
>>
>>
>>> On Sat, 25 Feb 2006 13:12:10 +1100, Wang Zhen <nehzgnaw@gmail.com> wrote:
>>>
>>>
>>>
>>> [snip]
>>>
>>>> How different is enum from constants then?
>>>
>>>
>>> I agree. I thought enum were invented as a shorthand way of doing ...
>>>
>>>   const int red = 1,
>>>             blue = 2,
>>>             green = 3;
>>>
>>> Instead we can do 'enum colors { red, blue, green }'
>>>
>>> To saving the coder having to recalculate the 'enumerated' names when some were added or deleted.
>>>
>>>   const int red = 1,
>>>             yellow = 2,
>>>             blue = 3,
>>>             green = 4;
>>>
>>> Instead we can do 'enum colors { red, yellow, blue, green }'
>>>
>>> Otherwise they are just constants of varying values.
>>>
>>> --Derek Parnell
>>> Melbourne, Australia