Mark, First of all, "type T" in C++ is rather different in that it is a specification that T denotes a type, it is NOT an operator as such. In your example, I am assuming that you want "type(T2)" to *conditionally* bind to T::T2 or type(int) depending on whether T2 exists in T or not. That is not at all what C++ does. In C++, "type T" means "treat the token T as a type" and is only needed once in a context to deal with parsing ambiguities. In your approach you would need to use "type(T2)" on each occurrence of T2 since "type" is an operator in SV and it is being used not to indicate a static constraint (that T2 is a type) but rather as a magic "defer the name lookup" operation. T2 could still bind to either a type or a variable. You didn't address what a bare "T2" means -- is it illegal? Does it mean the T2 in child? You've also argued that the special resolution only occurs in methods. How do you align that with your example here? And if you generalize your rules, how are you going to address all the other problematic cases that I raised earlier? Finally, types now appear to be completely different in your approach -- you need some sort of explicit indication for those but not for other things. Gord. Mark Hartoog wrote: > 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 >> >> -- -------------------------------------------------------------------- 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.Received on Mon Sep 10 10:12:51 2007
This archive was generated by hypermail 2.1.8 : Mon Sep 10 2007 - 10:13:01 PDT