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

This is not very consistent with the rest of the Verilog 
language. 

If I have:

class C;
  typdef logic[3:0] T;
endclass

C c; // class handle to 'C'

C::T x; // variable of type C::T.

Now I change class C to be:

class C #(WIDTH = 4);
  typdef logic[WIDTH-1:0] T;
endclass

C c; // class handle to 'C' with default parameter value

C::T x; // Now illegal. Must be changed to "C#()::T x;" 

If someone has a class that is not parameterized, and decides to add 
a parameter with an appropriate default value so they do not break any 
existing usages of the class. With your proposal now they have to go 
through all the design and change every static reference to class
objects 
to C#()::T. 

I think this change will discourage good code resuse practices and be
viewed as inconsistent with the rest of the verilog language, in
addition
to creating substantial backwards incompatability with P1800-2005.

> -----Original Message-----
> From: Francoise Martinolle [mailto:fm@cadence.com] 
> Sent: Thursday, October 04, 2007 10:29 AM
> To: Gordon Vreugdenhil; Mark Hartoog
> Cc: SV_EC List
> Subject: RE: [sv-ec] "::" is ambiguous in parameterized classes
> 
> I do agree with Gordon. C:: should only mean a class scope.
> It was a mistake when we allowed C:: to mean the default 
> specialization as a short cut for typing C#()::. That was the 
> only reason we did that a year ago. We do not have any 
> advantage in having this mean the default class 
> parameterization, all it creates is confusion.
> 
> Francoise
>     '
> 
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On 
> Behalf Of Gordon Vreugdenhil
> Sent: Thursday, October 04, 2007 1:23 PM
> 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.
> 
> 

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