[sv-bc] invalid enum values

In looking at the text related to assigning out of range values to an
enumeration variable, I discovered contradictory things.

Section 3.10.3 says
"The result of any operation on an enumeration variable after the variable
has been assigned an out of range value shall be undefined."

However, looking at operations specific to enums, 3.10.4.3 says
"If the given value is not a member of the enumeration, the next() method
returns the first member."

Section 3.10.4.4 says
"If the given value is not a member of the enumeration, the prev() method
returns the last member."

Section 3.10.4.6 says
"If the given value is not a member of the enumeration, the name() method
returns the empty string."

Assuming that a value that is not a member of the enumeration is the same
thing as an out of range value, the results of these operations seem to
be pretty well defined.

The other predefined methods don't care what value is in the enumeration,
because they just return a property of the type (first, last or number of
elements).

So what are these supposed undefined operations? The only thing left
is the use of an enumerated type variable in a numerical expression. In
that case, I would expect it to have the numerical value that was just
assigned to the underlying variable. What else would be the point of
allowing the casting of an arbitrary numerical value for assignment to
the type? Can anyone shed light on what was intended?

Also, does anyone know whether there were specific reasons why the next()
and prev() methods were defined to return the first and last members? For
4-state enums that were initialized to an out of range X value, it would
be nice if next() and prev() returned X. Defining these to return the
initialization value for an invalid value would be one way to do that.
Note that if a 2-state enum still uses the first value as the initialization
value, this would keep the same behavior for next(), but change the behavior
for prev(). Does anyone actually care, or were these just arbitrary
decisions made to give a semi-sensible valid value back?

Having this information would make it easier to propose something for 216.

Steven Sharp
sharp@cadence.com
Received on Wed Oct 27 17:03:04 2004