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

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.
> 

-- 
--------------------------------------------------------------------
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.