RE: [sv-ec] Re: [sv-bc] operators and data type compatibility rules

Steve,

Thanks for pointing out my mistake.

I was trying (poorly) to make the point that we should not change the
equivalency requirement rule. I believe the one unresolved problem is
that when dealing with classes, the assignment operation is asymmetrical
(upcast vs downcast). And, in that situation, we still need to define
the type of the result.

	Arturo

-----Original Message-----
From: Steven Sharp [mailto:sharp@cadence.com] 
Sent: Friday, September 15, 2006 5:38 PM
To: gordonv@model.com; fm@cadence.com; Arturo.Salz@synopsys.COM
Cc: Arturo.Salz@synopsys.COM; sv-bc@eda.org; sv-ec@eda.org
Subject: RE: [sv-ec] Re: [sv-bc] operators and data type compatibility
rules


>From: "Arturo Salz" <Arturo.Salz@synopsys.com>

>But, if we did go that way, the result of the comparison will always be
>false - with one exception: when both handles are null in which case
the
>result is still the same (ie null). 
>The I would suggest we simply rewrite 
>	a = cond ? b : c;
>as
>	a = null;
>
>So what's the advantage of removing the restriction?


Arturo,

Don't forget that the comparison between b and c is only performed
if the condition is X.  Also, b and c could be equal even without
having equivalent types, if we assume that they are equal when they
point to the same object.  One of them could be of a class that is
a base type of the other, so that both could point to the same object
of a mutually derived type.

So this is equivalent to a=null only when the condition is X, and
neither b or c has a type that is a base class of the other.

The full equivalence would be more like

  if (|cond === 1'b1)
    a = b;
  else if (|cond === 1'b0)
    a = c;
  else if (b == c)
    a = b;
  else
    a = null;
    
If neither b or c has a type that is a base class of the other, but are
both derived from the type of a, then this is equivalent to

  if (|cond === 1'b1)
    a = b;
  else if (|cond === 1'b0)
    a = c;
  else
    a = null;

Which is still much more useful than a=null.

I don't know whether this kind of thing is useful enough to justify
the extra complexity in describing the rules in the LRM.  The user
can always throw in casts to make it work, even if the LRM requires
the types to be equivalent.  That would certainly make it clearer what 
the code means.

Steven Sharp
sharp@cadence.com