RE: [sv-bc] 4.10.4 "Enumerated types in numerical expressions" - unclearness

So what you and Dave seem to be saying is that the next() method
increments the enum value by 1 and then casts it back to the enum type.

This interpretation is certainly not clear from the text.
I had interpreted the text to mean that next() goes to the next member
in the list of members. Otherwise, why not simply say that it increments
the value, as I wrote above? Especially as the description of next()
immediately follows the descriptions of first() and last(), which
likewise refer to order in the list, as opposed to maximum and minimum
values.

Assuming that I interpret you correctly, that still leaves some open
questions.

It means for example, that the example in 4.10.4.7, of how to display
the name and values of all the members of an enumeration, is not
general, as is implied. It would only work if indeed each member has a
value incremented by 1 from the member preceding it in the list.


Also, you wrote,
" And if you haven't
>explicitly
>defined an enum member with an all-X value (which you generally
>won't),
>subsequent next() calls will continue to produce X"

It would seem to me that this will occur even if you have defined an
enum member with an X value. Incrementing X by 1 will still give you X.
So if you start from X, next() will leave you stuck there. And if you
start from a non-X value, next() will never bring you to the X value.

By the way, I can declare a net as an enum, can't I? In that case, its
default initial value would be Z, not X, right?


Another question is about what is written is that "A wrap to the start
of the enumeration occurs when the end of the enumeration is reached."
So what happens if the last member in the enumeration list is not the
maximum value in the list?
Similarly, prev() mentions "when the start of the enumeration is
reached".


Finally, I want to go back to one of my previous questions.

4.10 says, "If an automatically incremented value is assigned elsewhere
in the same enumeration, this shall be a syntax error."

And 4.10.3 says, "Both the enumeration names and their integer values
must be unique." It is unclear what "their integer values must be
unique" means. It could mean that I may not assign two different values
to the same name, as it says explicitly two sentences later, or it could
mean that I may not assign the same value to two different enumeration
names. It says, "It is an error ... to set a value to the same
auto-incremented value," which is the same as quoted above in 4.10.

But does this mean it is allowed to assign the same value twice
explicitly? If so, what would name() give me in this case?

Thanks,
Shalom


>>I don't know how to reconcile these. What is the case being
>described,
>>that "the given value is not a member of the enumeration"?
>
>Despite the claim of "strong typing" in the LRM, there are a
>number of
>ways that an enum object can get a value that is not a member
>of the
>enumeration.  For example, you can explicitly define an enum
>whose
>numeric values are all even numbers, and then use a cast to
>assign an
>odd number to it.  Or you can define a int enum with 10
>members, which
>get assigned numbers 0-9, put it in a union with an ordinary
>int, and
>assign 100 to the int, which puts 100 into the enum int also.
>
>Then if you invoke the next() method, the value being given to
>the
>method is not a member of the enumeration.  This LRM statement
>then
>says that the result of next() will be the default initial
>value for
>the enumeration.  This is X for a 4-state enum, which is what
>you
>would expect for an undefined operation.  And if you haven't
>explicitly
>defined an enum member with an all-X value (which you generally
>won't),
>subsequent next() calls will continue to produce X.