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.