Mark, Once again you are assuming that your interpretation is what the LRM definitively states. I disagree. By your argument, $unit:: should also be disallowed since, after all, one can just rename to avoid any name ambiguities. Finally, if a user *does* write the code I did but did so indirectly due to effects of macro expansion of identifiers, I am claiming that the meaning is ambiguous and that the most natural interpretation is the one that I suggest. Gord. Mark Hartoog wrote: > This issue exists because you have named both your type > parameters 'T'. The sensible solution is to name your type parameters > something different, then you would not have this problem. > > class C #(type T1 = int); > class B #(type T2 = T1); > T1 x; > endclass > endclass > > I'm not sure that naming all your nested type parameters 'T' is a coding > style that we should be changing the language to make easier to > use. > >> -----Original Message----- >> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On >> Behalf Of Gordon Vreugdenhil >> Sent: Thursday, October 04, 2007 8:35 AM >> To: SV_EC List >> Subject: [sv-ec] "::" is ambiguous in parameterized classes >> >> >> This issue came up at the last EC meeting. >> >> Consider the following: >> class C #(type T = int); >> class B #(type T = C::T); >> C::T x; >> endclass >> endclass >> >> The "::" here has two interpretations -- class scope >> resolution and resolution into a *type*. In this situation >> there is a difference since the name "C" is overloaded to >> mean both the name of the class and the name of the default >> specialization. >> >> I think that the user intent here is that "C::T" should mean >> "T" in the enclosing scope and NOT "T within the default >> specialization of C". If the latter interpretation is >> chosen, then there is no way at all to refer to the unspecialized "T" >> from C from within the nested class. If the scope resolution >> interpretation is intended, one can refer to the default >> specialization as "C#()::T". This is particularly important >> for the default in "B" -- it seems clear to me that the >> expected intent would be "I want B to default to the type >> used to specialize C". >> >> Putting this along side my comments in >> http://www.eda-stds.org/sv-ec/hm/4647.html >> I think there is now a compelling argument to clarify the LRM >> by stating something like the following: >> When used with a parameterized class prefix, the "::" resolution >> operator shall only be legal within the parameterized class named >> in the prefix or an out-of-block method declaration of that >> parameterized class. With a parameterized class prefix, the "::" >> resolution operator shall only disambiguate names, it shall not >> refer to the default specialization of the class. >> >> I will add the example above when I write up a proposal for this. >> >> 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. >> >> -- -------------------------------------------------------------------- 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 Thu Oct 4 10:23:34 2007
This archive was generated by hypermail 2.1.8 : Thu Oct 04 2007 - 10:23:56 PDT