[sv-bc] RE: Resolution of inherited type names

In C++ they introduced the typename keyword for cases 
were it was ambiguous if something was a type or not at
parse time:

template <class T>
   class foo {
      typename T::T2 x;
   };

The 'typename' keyword indicates that 'T::T2' must be a type.

In System Verilog we do not need any new keywords, since we 
already have the type operator for these cases:

     module child #(type T = int);
       int T2;
       class C extends T;
          type(T2) x;
       endclass
     endmodule 

> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
> Sent: Friday, September 07, 2007 3:12 PM
> To: SV_EC List; Mark Hartoog; SV_BC List
> Subject: Resolution of inherited type names
> 
> Mark, I think I raised this once a long time ago but I'll 
> raise it again since I think we've both neglected to discuss 
> this scenario.
> 
> Given your rules, I don't think you can have symmetric 
> handling of type names versus member/property names when 
> inheriting from an opaque type.  Specifically, what rules 
> would you apply when dealing with something like the following:
>     module child #(type T = int);
>       int T2;
>       class C extends T;
>          T2 x;
>       endclass
>     endmodule
> 
> In order to be consistent with your approach elsewhere, would 
> you have to assume that "T2" is an inherited type and defer 
> all of the handling until elaboration?  Is that even possible 
> to parse in general if you don't know whether T2 denotes a 
> type or a variable?
> 
> I suspect that for inherited types in such a situation you 
> would have to adopt an approach similar to mine, would you not?
> 
> My suggested approach to solving such a scenario is similar 
> to what I want to do in every case; require explicit 
> referencing.  Here, I'd either be willing to allow something 
> like "typedef T::T2 T2;"  or "typedef super.T2 T2" to 
> directly declare that "T2" is an inherited type.  In the long 
> term, as I've suggested before, I'd like a more complete 
> "specification" for "T" that would directly give the 
> assumptions about what T provides rather than working from 
> indirect information in the body of C.
> 
> Gord.
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil                                503-685-0808
> Model Technology (Mentor Graphics)                gordonv@model.com
> 
> 

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