RE: [sv-ec] Re: [sv-bc] Queries on enum name method

>> it is not clear, how given value can be out side the member of enumeration.
>
>It's perfectly clear.  Here are two possible ways to get that,
>both explicitly legitimised by the LRM:

Other ways that may not be explicitly mentioned:

Declaring a union of an enum with a member of another type, writing to
the other member, and reading back the enum member.

Declaring a packed struct containing an enum, writing to the vector
that is the packed struct, and reading back the enum member.

Declaring a net of enum type, and then causing driver contention on it.

Declaring a DPI import function that returns an enum, but having the
C implementation return an invalid value.


>> 'A' can't be assigned by '1' or '0'

The LRM tries to describe enum values as if they were these abstract
values CC and DD, which are converted to 0 and 1 when used in an
expression.  But the way that it really works is that A holds the
values 0 and 1, and CC is just a name for 0 and DD is a name for 1.
When people start talking about the details of how enums work, which
includes the ability to hold values other than those represented by
any defined enum constant, we have to set aside the facade and talk
about the real representation.


>With regards to your first question, the LRM is suffering
>slightly because we don't have a neat terminology for
>"the thing to which a method is applied" - for example,
>"e" in "e.name".  I'm tempted to suggest calling it 
>the subject of the method, but perhaps the analogy with
>natural language syntax is too open to misinterpretation.

Wouldn't it be a little more accurate to call it the object of
the method, since it is what the method acts upon?  Plus of course
the pun value for classes...

Steven Sharp
sharp@cadence.com


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