Re: [sv-bc] Assignment compatibility of packed arrays of enums

> The question ... is what the LRM requires when an
> enum element or field that's been abused by type-unsafe
> assignment is fetched as an enum value.
> Is a compiler justified in thinking this value is confined
> to the enumerated set of values?

Surely not.  The value is still there in the underlying
representation.  It will compare as unequal with any of
the enum literals.  It can be auto-cast to an integral
value by appropriate (ab)use of the enum variable. And
if one of the enum methods such as .next() is applied
to it, the LRM mandates the result to be the default
initial value for the underlying type.  All this is
clear enough, though perhaps a little stressful for
milquetoasts such as me who were brought up on VHDL
enumerated types.

It is tiresome that there seems to be no clean way to
express the assertion that an enum variable's value is
legitimate; testing the string result of .name() for
non-zero length is ugly and obscure, and this is
unduly verbose:
  assert ($cast(enum_var, integer'(enum_var)));

It would be nice if the "inside" operator were
extended to allow an enum type name to appear
as its right-hand side.  (It would also be rather
nice if "foreach" could iterate an enum variable
over the values of its type, and any variable over
the values of an "inside"-style open_range_list.
That's on my wish-list for any future PAR.)
--
Jonathan Bromley
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.