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

Hi Gordon,

I had the same reaction as Neil when I first read the proposal.
(At least I think I did).  What you propose below does sound helpful,
but I don't think it addresses the issue Neil and I questioned.

The core of the issue is the special powers given to typedef in
the example you used.  i.e., A typedef of a generic class name
somehow promotes it into the default specialization of the class.

The closest justification I can find for this interpretation in
P1800-2008_D4 is this excerpt from the end of 8.24:

   A generic class is not a type; only a concrete specialization
   represents a type. In the example above, the class vector becomes
   a concrete type only when it has had parameters applied to it,
   for example:

      typedef vector my_vector; // use default size of 1
      vector#(6) vx; // use size 6

   To avoid having to repeat the specialization either in the
   declaration or to create parameters of that type, a typedef
   should be used:

      typedef vector#(4) Vfour;
      typedef stack#(Vfour) Stack4;
      Stack4 s1, s2; // declare objects of type Stack4

Is there any text elsewhere I may have missed?

If you really want it to be the case that a typedef of a generic
class indicates the default specialization of the class, I think
some normative text will be required in the LRM.  I can try to
cook something up to help out if that's the intention.

Thanks,
Doug



-----Original Message-----
From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On Behalf Of Vreugdenhil, Gordon
Sent: Friday, November 16, 2007 3:56 PM
To: Neil.Korpusik@Sun.com
Cc: SV_EC List
Subject: 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.


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