RE: [sv-bc] Resolving a forward typedef via a package import

 
I remember the discussion when we added this. I think I objected to the
last sentence
being added. However it was argued that it was for completion that we
needed to
add this sentence: a typedef can also come from a package.


    typedef ab;

    class a;
        ab m1;
    endclass
    import pkg1::ab;

I agree with Gordon that typedef ab is NOT a reference to ab. It is a
declaration in that scope.
Not a full declaration but a declaration.
Because it is a declaration, the import pkg1::a constitutes a duplicate
declaration and that should be
an error.


You could however do this:
   typedef ab;
   class a;
      ab m1;
   endclass

   typedef pkg1::ab ab;

The last typedef creates a full type declaration for ab which is an
alias of pkg1::ab

Francoise
    '

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Rich, Dave
Sent: Friday, September 29, 2006 1:20 AM
To: Greg Jaxon; Vreugdenhil, Gordon
Cc: Brad Pierce; sv-bc@eda.org
Subject: RE: [sv-bc] Resolving a forward typedef via a package import

Let's get practical here. Why would someone need to forward typedef a
type that is defined in a package? The purpose of a forward typedef is
to break circular type dependencies within a local scope. You can't have
circular package dependencies; therefore you should never need to
forward typedef a type that will be later imported.

So I agree with Greg in that this final sentence in 4.9 should be
removed.

Dave


> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
On
> Behalf Of Greg Jaxon
> Sent: Thursday, September 28, 2006 5:43 PM
> To: Vreugdenhil, Gordon
> Cc: Brad Pierce; sv-bc@server.eda.org
> Subject: Re: [sv-bc] Resolving a forward typedef via a package import
> 
> This also makes me uneasy.
> 
> Consider the problem of establishing the unique identity
> of this type in the instantiation hierarchy.   I assume
> that a typedef forward can only be completed by a full typedef /in the

> same scope/, so that both have the same
> full hierarchical name.   If it helps to consider an
> implementation, imagine that the forward typedef actually produces the

> basic type identity sans structural info.
> References to the incomplete type may refer to this record location, 
> and the completion simply fills in the details under the previously 
> reserved identity.
> 
> An import affects the receiving scope like a declaration.
> But so does the forward typedef.  I say they collide and do not form a

> completed pair.
> 
> Greg
> 
> Gordon Vreugdenhil wrote:
> >
> > I'm not quite sure that I buy your example.
> >
> > If you have:
> >    typedef ab;
> > ....
> >    import pkg1::ab;
> >
> > I can buy that as a completion of the forward, but what you are 
> > asserting is that the forward typedef is completed *upon its 
> > declaration* if the type is is a candidate from some package.
> >
> > That isn't an obvious conclusion from the text and is one that I am 
> > not sure I agree with.
> >
> > An implication of such a statement is that if ANY package has a 
> > visible type "T" then you can't forward declare "T"  even if your 
> > intent was to have the declaration complete locally.
> >
> > I would contend that the forward declaration does NOT count as a 
> > reference and the the completion must either be via an explicitly 
> > named import or by a subsequent typedef.
> >
> > So
> >    typedef ab;
> > ...
> >    typedef pkg1::ab ab;
> > would be fine as would my earlier example, but your example would 
> > not.
> >
> > Gord.
> >
> >
> > Brad Pierce wrote:
> >
> >> According to the final sentence of 4.9,
> >>
> >>    "Importing a typedef from a package into a local scope can also
> >>     resolve a type definition."
> >>
> >> It would be helpful to add an example of that, such as,
> >>
> >>     package pkg1;
> >>       typedef struct {logic a, b;} ab;
> >>     endpackage
> >>
> >>     package pkg2;
> >>       import pkg1::*;
> >>       typedef ab;
> >>     endpackage
> >>
> >>     module test(input a1, b1, output a2, b2);
> >>       import pkg2::*;
> >>       assign '{a2, b2} = ab'{a1, b1};
> >>     endmodule
> >>
> >> -- Brad
> >>
> >>
> >