RE: [sv-bc] enumerated variable used with an equality operator

A particular case we had recently was where someone wanted to declare two enum types that were variations of each other, and did not want to have to rename all the names that were the same.

From: Daniel Mlynek [mailto:danielm@aldec.com.pl]
Sent: Wednesday, March 26, 2014 10:01
To: Bresticker, Shalom
Cc: Greg Jaxon; sv-bc@eda.org
Subject: Re: [sv-bc] enumerated variable used with an equality operator

IMHO current behaviour that 2 enums cannot have same enum labels is ok, also strong type checking only for assigning to enum is ok.

I think that there can be many arguments to support my point of view ie:
-  it is bad idea to deliberately define the behaviour of features well known  in programing in the opposite way that it is defined in other languages like ie C++.
- it is not good idea to use same label in 2 enums - different enums should describe different types so why they has to have same names
- If user really wants to have 2 enums with same enum label he can define them in different scopes ie packages.


DANiel
W dniu 3/26/2014 8:43 AM, Bresticker, Shalom pisze:
In a somewhat similar vein, there is sometimes a problem with two enum type declarations that use the same value names.

Example:

typedef enum { A, B, C } e_1 ;
typedef enum { C, D, E } e_2 ;

Currently you get a fatal syntax error on multiple declarations of C.

I would like to propose that a case like this be treated like importing packages.

That is, you would not be able to reference C directly, but you would be able to write e_1::C.

Shalom

From: owner-sv-bc@eda.org<mailto:owner-sv-bc@eda.org> [mailto:owner-sv-bc@eda.org] On Behalf Of Greg Jaxon
Sent: Friday, March 21, 2014 20:37
To: sv-bc@eda.org<mailto:sv-bc@eda.org>
Subject: Re: [sv-bc] enumerated variable used with an equality operator

ISO-C 5.5 holds that two enum types are always distinct.
Following tradition, if Verilog has the same syntax as C, it must take on a different meaning.
To appeal to folks who believe in this guiding principle, I can offer them this suggestion:
The enum label exported to the declaring scope will be strongly typed (C-like), but if you select it
directly out of the enum scope itself, it will be weakly typed.
Thus  TRUE == FALSE would be a type-mismatch error in a scope where these were labels of distinct enums,
even though BLUE::TRUE == TEETH::FALSE would be legal, and perhaps true.
There, is that different enough from C so the pain of matching it elsewhere is diminished? ;-)

On 3/21/2014 12:16 PM, Brad Pierce wrote:

Enum types should be 100%-strong with the base type encodings accessible

via an enum method as in http://www.eda.org/svdb/view.php?id=4887 .



Such a method would still be useful even if weak enum typing must be

preserved for legacy reasons.



Replying to http://www.eda.org/sv-bc/hm/11537.html .



-- Brad








--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.