Re: FW: [sv-bc] Parameterizing functions using classes -- ballot issue 225

Gord is justifiably confused about class specialization.
Elsewhere the LRM has insisted that:

    1)  struct { int a,b,c } a;
        struct { int a,b,c } b;    // have different type

    2)  Distinct interface instantiations (even with identical
        parameters) are distinct interfaces, which do not share
        their static declarations.

Specialization of classes needs to break this pattern so that
parameterized modules don't have to also receive the correspondingly
specialized classes they'll exercise. We want generic modules to refer to
generic class specializations as needed by simply repeating the
specializing syntax.  It's going to be up to some linkage step to
unify all the static members of specialized classes.  Classes are
levers for operating the linkage machinery.

I'm pretty sure that is the design intent.  The LRM text has not
been sufficiently definitive here if it has confused so careful
a reader as Gord.

I expect that static objects connected this way are not synthesizable.

Greg

Brad Pierce wrote:
>>Gordon Vreugdenhil wrote:
>>
>>Arturo Salz wrote:
>>>Are you seriously suggesting that in
>>>this example, objects a and b are different types?
>>>
>>>    C#(5) a = new;
>>>    C#(5) b;
>>>
>>>    b = a;    // is this illegal?
>>
>>Absolutely.
>>
>>If you want the types to be the same, you must create a typedef
>>that makes a unique instantiated type.
>>
> 
> 
> Then, what about
>     typedef C#(5) c_5;
> Would you suggest that C#(5) and c_5 are incompatible types?
> Consider the matching type rules:
> 
>     2) A simple typedef or type parameter override that renames a built-in
>         or user-defined type matches that built-in or user-defined type
> within
>         the scope of the type identifier.
> 
>     4) A typedef for an enum, struct, union, or class matches itself and
>         the type of data objects declared using that data type within the
>         scope of the data type identifier.
> 
> I take that to mean that x and y below are matching types:
>     c_5 x;
>     C#(5) y;
> But, I guess you'd argue that they are incompatible.