Re: [sv-bc] typedefs in separate compilation units

Francoise,

     I think it is also the LRM's intent that identical types declared in
the "global" scope (what used to be called $root) are considered
identical under reasonable conditions that might arise during a separate
compilation methodology.  This is not to say that /every/ repetition of
a type (from, say an included header file) is identical to every other,
I believe the LRM wording requires clones to be distinguished when their
definition is read into distinct scopes, and certainly if the inclusions
preprocess down into distinct layouts for the datatypes.

     In my view, the whole reason for choosing "type identity" over
mere "structural conformity" is to make separate compilation (and 3rd party IP)
much safer to use.  Type identity not only captures the
concept of functional equivalence, it can also guarantee that
two types descend from a single point of control.  We check that both
parties in the equivalence relation have their type info from the same
source and the same chain of deployment decisions about how that IP
source is to be used.  This protects users from coming to rely upon
an equivalence which is merely an accidental alignment of IP choices.
I think (hope?) this level of control is improved by the addition of package
scopes.

     It is hard to express these software engineering concepts in
committee-written and edited LRM text.  But I hope I'm not just reading too
much into the current wording.  If you find that the LRM contradicts
the interpretation I just offered, please suggest better wording so
that SV actually achieves this goal.  Strong typing is a big pain;
it has to pay off by delivering a meaningful gain.

Greg Jaxon


Francoise Martinolle wrote:
> It seems that the definition of type compatibility does not
> consider the practical case of separate compilation units.
>  
> Consider a global typedef declared at the compilation unit scope.
>  
> Consider the same exact global typedef declared in another compilation unit.
>  
> The design brings these two compilation units together.
>  
> I think it is the user intent that these types be compatible such that
> ports connecting objects of these types are legal and assignment of values
> of objects of these types are also legal.
> Is that not the case?
>  
> Francoise
>        '