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

From: Gordon Vreugdenhil <gordonv_at_.....>
Date: Thu Oct 04 2007 - 10:23:11 PDT
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