Static fields in specialized classes

[Vitaly Davidovich]

"Under specialized generics, there is one class for all reference types
(same game as before), and one specialization for each primitive/value
instantiation.  (This is not unlike what C# does under the hood; it
compiles one set of native code for erased references, and one set per
unique struct instantiation.)"

In the CLR, the fact that structs get unique native code is a design
issue/restriction due to variable size of structs (refs are easy since
they're all same size pointers).  In theory, structs of equal layout could
share machine code.

How's this going to work for generic methods that are constrained to take
an interface type and thus allow structs/value types to be passed in?
Specifically, in .NET this allows avoiding boxing of struct arguments.  Is
generic method specialization going to address that?

Will reflection allow introspection of generic types and provide
information about the generic definition? Will it be possible to
instantiate a generic type specialization via reflection/late-binding?

Finally, there's a neat use case in .NET regarding generic types and static
fields of that generic type.  For example, there's a generic abstract class
called Comparer<T>.  It has a property called Default, which returns a
Comparer<T> suitable for comparing T instances.  Internally, it decides
what comparer to use by inspecting aspects of T.  The end result is you get
a comparer that will avoid boxing of structs if T is a struct.  Is
something like that going to work in what you guys are thinking of?

Sent from my phone
On Oct 13, 2014 9:21 PM, "Brian Goetz" <brian.goetz at oracle.com> wrote:

> I think you're making some assumptions about the goals here which are not
> accurate.  You talk about "reification" like we're going to drop existing
> generics and adopt something like what C# did.  That's not what's going on.
>
> (The elephant analogy is apt, since it seems that everyone has their own
> idea of what reified generics means... :)
>
> So, to be clear, reified generics isn't the primary goal here.  (It so
> happens that specialized generics *are* reified, but that's a side-effect
> of the implementation strategy rather than the goal, and actually a
> semi-problematic one at that.)
>
> On 10/13/2014 7:04 PM, Vitaly Davidovich wrote:
>
>> The issue is that since java doesn't reify generics, users know that
>> there's just one type.
>>
>
> No, there's many types, there's one *class*.  The Java language has a type
> system, and the VM has a type system, and they're different.
>
> Under specialized generics, there is one class for all reference types
> (same game as before), and one specialization for each primitive/value
> instantiation.  (This is not unlike what C# does under the hood; it
> compiles one set of native code for erased references, and one set per
> unique struct instantiation.)
>
>  My argument is that if there's reification, then
>> generic classes take on a different meaning (to me)
>>
>
> There's nothing wrong with this argument if you were starting from a blank
> sheet of paper.  You could define things to work however you want.  But
> that's not what we're doing here; we're doing that in the context of Java
> having had erased generics for ten years (and people only recently wrapping
> their heads around how generics work.)  We're not going to pull the rug out
> from under users like that.
>
> (Remember, even if we did try to do some sort of full blown reification,
> we'd *still* have to deal with erasure, as old classfiles that instantiate
> erased instances would have to keep working.)
>
>