Re: [sv-ec] parameterized class "::" operations and out-of-block declarations

From: Gordon Vreugdenhil <gordonv_at_.....>
Date: Mon Nov 19 2007 - 07:43:23 PST
Neil, I'm fine with all the suggested changes with one minor
difference.  You had added "C:: not allowed in this scope"
in the example:

    int x = C::p;     // illegal; C:: not allowed in this scope

I'd prefer "context" to "scope".  The rule is really a
context rule, not truly just "scope" since 'C::' could be legal
in an out-of-body declaration that is still really in this scope.

    function C::T[C::p] C::f(); ... endfunction;

Based on the other discussion, I also changed the later comments
in the proposal.  It now has:

    typedef C T;	  // T is a default specialization, not an alias to the name “C”
    int z = T::p;  // legal; T::p refers to p in the default specialization

I think that helps to avoid the confusion of why "C" and "T" as
prefixes to "::" are not the same.

I'll upload the new version shortly.

Gord.


Neil Korpusik wrote:
> Hi Gord,
> 
> Yes, that change helps. Attached is a marked up version that has some
> other changes that I think improves the text. Stu told us yesterday
> that the word must has been deprecated by the IEEE, so we should
> make at least that set of changes. I forgot to add in the change
> that you are showing below. It should also be added.
> 
> After thinking over this some more, I am in agreement with what
> you are showing in the proposal. The typedef example is very
> useful, since it will catch some people by surprise.
> 
> 
> Neil
> 
> 
> 
> 
> 
> Gordon Vreugdenhil wrote On 11/16/07 03:55 PM,:
>> Neil, it is only in the context of a "::" prefix that you don't
>> get the default specialization.
>>
>> So given my class C:
>>
>>    C some_obj = new;
>>    struct { C field; } s;
>>    C some_arr[$];
>>
>>    some_module #(C) m();
>>
>> are all fine and "C" means "the default specialization" in those
>> contexts.  This preserves compatibility with the existing
>> LRM provisions and implementations.
>>
>> I should probably make sure that no one tries to apply the quoted
>> sentence out of context by saying:
>>
>>      When referencing a default specialization as the prefix to the
>>      class resolution operator, the explicit default specialization
>>      form of "#()" must be used.
>>
>> Does that help?
>>
>> Gord.
>>
>>
>>
>> Neil Korpusik wrote:
>>
>>> Hi Gord,
>>>
>>> I am having trouble understanding one aspect of your example (the use of the
>>> typedef). In the new proposed text there is the following statement.
>>>
>>>    References to the default specialized type must use the explicit
>>>    specialization form "#( )" with no actuals.
>>>
>>> But then in the example you are using a typedef which does not use "#()".
>>> The comment says that the typedef defines T to be the default
>>> specialization. I am having a problem seeing how this is so.
>>>
>>>   Example:
>>>      class C #(int p = 1);
>>>         static task t;
>>>            int p;
>>>            int x = C::p;  // C::p disambiguates p
>>>                           // C::p is not p in the default specialization
>>>         endtask
>>>      endclass
>>>
>>>      int x = C::p;    // illegal
>>>      int y = C#()::p; // legal; refers to parameter p in default
>>>                       // specialization of C
>>>      typedef C T;
>>> -->   int z = T::p;    // legal; the typedef defines T to be the default
>>>                       // specialization so T::p refers to the p in the
>>>                       // default specialization
>>>
>>> Neil
>>>
>>>
>>>
>>> Gordon Vreugdenhil wrote On 11/16/07 02:14 PM,:
>>>
>>>> I've uploaded a proposal for Mantis 1857 that I believe captures
>>>> the agreed upon behaviors from the last name resolution meeting.
>>>> Please review asap and let me know if there are any substantive
>>>> problems.
>>>>
>>>> Gord.
> 
> 
> ------------------------------------------------------------------------
> 
> Section 8.22
> 
>  
> 
> Change
> 
>  
> 
> class_identifier :: { class_identifier :: } identifier
> 
>  
> 
> The left operand of the scope resolution operator :: shall be a class 
> name, package name (see 25.2), *covergroup** *type name, *coverpoint** 
> *name or *cross *name (see 18.5, 18.6).**
> 
> TO:
> 
>  
> 
> class_identifier :: { class_identifier :: } class_type :: { class_type 
> :: } identifier
> 
>  
> 
> The left operand of the scope resolution operator :: shall be a class 
> type name, package name (see 25.2), *covergroup** *type name, 
> *coverpoint** *name or *cross *name (see 18.5, 18.6).**
> 
>  
> 
>            
> 
> Add at the end of existing 8.22 text:
> 
>  
> 
> The class resolution operator has special rules when used with a prefix 
> that is the name of a parameterized class; see 8.24.1 for details.
> 
>  
> 
>  
> 
> Section 8.23
> 
>  
> 
> CHANGE:
> 
>  
> 
> Out-of-block declarations must be declared in the same scope as the 
> class declaration.
> 
>  
> 
> TO:
> 
> Out-of-block declarations must be declared in the same scope as the 
> class declaration.
> 
> An out-of-block declaration must shall be declared in the same scope as 
> the class declaration and shall follow the class declaration.  It shall 
> be an error if more than one out-of-block declaration is provided for a 
> particular *extern* method.
> 
>  
> 
> The class resolution operator is required in some situations in order to 
> name the return type of a method with an out-of-block declaration.  The 
> return type of an out-of-block declarations is encountered declaration 
> shall be specified prior to the out-of-block indication for the method.  
> When the return type of the out-of-block declaration is defined in 
> within the class, the scope resolution operator must shall be used to 
> indicate the correct return type.
> 
>  
> 
> Example:
> 
>  
> 
> *class* C;
> 
>       *typedef* *int* T;
> 
>       *extern* *function* T f();
> 
> *endclass***
> 
> * *
> 
> *typedef* *real* T;
> 
>  
> 
> *function* C::T C::f();
> 
> *return* 1;
> 
> *endfunction*
> 
>  
> 
> Add at the end of existing 8.24 text:
> 
>  
> 
> 8.24.1    Class resolution operator for parameterized classes
> 
>  
> 
> Use of the class resolution operator with a prefix that is the unadorned 
> name of a parameterized class (see 8.24) shall be restricted to use 
> within the scope of the named parameterized class and within its 
> out-of-block declarations (see 8.23).   In such cases, the unadorned 
> name of the parameterized class does not denote the default 
> specialization but is used to unambiguously name refer to members of the 
> parameterized class.  References to the default specialized type must 
> shall use the explicit specialization form “*#(** )*” with no actuals.
> 
>  
> 
> Example:
> 
>  
> 
> *class* C #(*int* p = 1);
> 
>       *static* *task* t;
> 
> *            int *p;
> 
>             *int* x = C::p;     // C::p disambiguates p
> 
>                               // C::p is not p in the default specialization
> 
>       *endtask***
> 
> *endclass***
> 
>  
> 
> *int* x = C::p;                 // illegal; C:: not allowed in this scope
> 
> *int* y = C#()::p;              // legal; refers to parameter p in the 
> default specialization of C
> 
> *typedef* C T;
> 
> *int* z = T::p;                 // legal; the typedef defines T to be 
> the default
> 
>                               // specialization so T::p refers to the p 
> in the
> 
>                               // default specialization
> 
>  
> 
> In the context of a parameterized class method out-of-block declaration, 
> use of the class scope resolution operator shall be a reference to the 
> name as though it was made inside the parameterized class; no 
> specialization is implied.
> 
>  
> 
> Example:
> 
>  
> 
> *class* C #(*int* p = 1, *type* T = *int*);
> 
>       *extern* *static* *function* T f();**
> 
> *endclass***
> 
>  
> 
> *function** *C::T C::f();
> 
> *      return *p + C::p;
> 
> *endfunction***
> 
> * *
> 
> *initial *$display(“%0d %0d”, C#()::f(),C#(5)::f());    // output is “2 10”
> 
> * *
> 
>  
> 

-- 
--------------------------------------------------------------------
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 Mon Nov 19 07:44:09 2007

This archive was generated by hypermail 2.1.8 : Mon Nov 19 2007 - 07:44:46 PST