Re: [sv-bc] clarification on rules for enums

>From: Paul Graham <pgraham@cadence.com>
>
>In p1800 draft 6 section 4.10 on enumeration types defines
>error conditions which apply to enum literals that lack an
>explicit value specifier.  It is an error if incrementing
>causes a value overflow.  It is also an error if such a
>literal has a value which is used by another literal in the
>same type declaration.  The way the spec is worded, it
>appears that these errors don't apply to explicitly
>initialized enums.  Is this true?

Perhaps you missed the statement that says:

"Any enumeration encoding value that is outside the representable
range of the enum shall be an error."

This applies to an explicit value overflowing the size of the enum.


>      // no error, blue is explicitly initialized
>      // except that now blue (truncated to 2 bits) matches red
>    enum bit [1:0] {red, orange, yellow, green, blue = 4} color;

Error, since 4 is outside the representable range.

>
>      // no error, blue is explicitly initialized, so is red
>    enum bit [1:0] {red = 0, orange, yellow, green, blue = 4} color;

Error, since 4 is outside the representable range.

>      // no error, blue is explicitly initialized, so is red
>    enum bit [1:0] {red = 0, orange, yellow, green, blue = 0} color;

The LRM does not say that this is an error, and perhaps at one time
there was a desire to let the user explicitly give two different names
to the same value.  However, if this were allowed, the built-in methods
added later would not work.  When color holds a numeric value of 0, what
is color.name or color.next?  The numeric encodings must be unique for
the methods to work properly.

There is also a questionable statement that says:

"If any of the enum members are defined with a different sized constant,
this shall be a syntax error."

This seems to assume that the enums will be assigned only with literals,
so that this rule can be applied to the literal size.  It doesn't
generalize to what is actually allowed, which is an arbitrary constant
expression.  It can't mean that you use the size of the expression, since
the example says that unsized literals are OK, but unsized literals make
the expression 32 bits wide or more, which would violate the rule.  And
if you try to make a special exception for unsized literals, then what
about expressions that include unsized literals and have their size affected
by the unsized literal?  Are they errors because the size was wrong?  But
the size was wrong because of an unsized literal, which is not supposed to
be treated as the wrong size.  Does that make it OK?  But what if the size
would have mismatched even without the unsized literal present?

Ultimately, that rule doesn't make sense anyway.  What matters is whether
the value specified fits into the enum, not what expression was used to
specify the value.

This rule may have been a holdover from an attempt to make the enums
auto-size based on the sizes of the explicit constants.  That would have
required the sizes to match.  Without that, the rule is unnecessary, as
well as being incomplete and unclear.

Steven Sharp
sharp@cadence.com