RE: [sv-bc] confusion in determining the type of an self determined binary expression during evalution of type operator

>From: "Feldman, Yulik" <yulik.feldman@intel.com>

>I would say that you need to normalize only if the types of then- and
>else- expressions do not match. If the types are matching (or "same"),
>it would be more useful to let the conditional operator return this
>type, rather than to artificially normalize it. This is especially true
>for non-integral types.

I agree for the non-integral types where strong type matching is required.
Mantis 1594 and 1608 address the rules for classes.

For integral types, I don't see any reason to attempt this.  There are
already complex rules for determining the properties of the type in the
general case.  I don't see a reason to add more complexity with added
rules that only apply in a few special cases anyway.  Then users have
to know the extra rules, and the rules for when they apply.  What is
the use model that gets an advantage from adding this complexity?


>Aside conditional operators and identifiers, mentioned in this mail
>thread, other expressions that may (should be defined as able to) have a
>type other than a simple scalar or a "normalized" one-dimensional vector
>are part selects, cast operators, assignment operators, assignment
>patterns and maybe others.

I agree that the result type of a cast operator is clear.  The result of
an assignment operator is already specified to have the type of what it
was assigned to, so that is clear too.  An assignment pattern has a clear
type, but I think that only matters for assignment compatibility, since
they cannot be used in any other contexts.  An assignment pattern
expression has a clear type.

I'm not convinced about part selects.  Can you provide any examples of
where it is even useful that they maintain the range?

Steven Sharp
sharp@cadence.com


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