www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - non-integral enums?

reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----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







3) enables struct enums














Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFD/3UA3w+/yD4P9tIRAvbrAKCRJVzOd8tgfu3yUJqoy7spILy9XgCfbq/q
9pwmXsSd/EhVdNJsoNN1tOc=
=LEQd
-----END PGP SIGNATURE-----
Feb 24 2006
next sibling parent reply Tom <Tom_member pathlink.com> writes:
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







3) enables struct enums















Don't you forget string enums. That would also be NICE!

Tom;
Feb 24 2006
parent Chris Sauls <ibisbasenji gmail.com> writes:
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







3) enables struct enums















 
 
 Don't you forget string enums. That would also be NICE!
 
 Tom;


A-bleeping-men.

-- Chris Nicholson-Sauls
Feb 24 2006
prev sibling parent reply Wang Zhen <nehzgnaw gmail.com> writes:
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
 





 
 3) enables struct enums
 












 
 Thomas
 
 
 -----BEGIN PGP SIGNATURE-----
 
 iD8DBQFD/3UA3w+/yD4P9tIRAvbrAKCRJVzOd8tgfu3yUJqoy7spILy9XgCfbq/q
 9pwmXsSd/EhVdNJsoNN1tOc=
 =LEQd
 -----END PGP SIGNATURE-----



How different is enum from constants then?
Feb 24 2006
parent reply "Derek Parnell" <derek psych.ward> writes:
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
Feb 24 2006
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
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
Feb 24 2006
parent reply Chris Sauls <ibisbasenji gmail.com> writes:
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
Feb 26 2006
parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
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
Feb 26 2006