RE: [sv-ec] "::" is ambiguous in parameterized classes

In a similar situation in more scopes, there is no way to refer to
a masked type identifier:

module m #(type T = int); 
task t;
parameter type T = logic;
m.T x; // illegal, hierarchical references to type not allowed.
endtask
endmodule

I do not see why we should be making incompatible changes in the
language
in order to make it easier for users to totally confuse themselves by
masking
identifiers with duplicate names.

> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
> Sent: Thursday, October 04, 2007 10:23 AM
> To: Mark Hartoog
> Cc: SV_EC List
> Subject: Re: [sv-ec] "::" is ambiguous in parameterized classes
> 
> 
> 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.