more background to List<int> specializing List<Any>

[Brian Goetz]

More likely: if we took value types out of the picture, we might well 
not bother with specialization at all; we've limped along without it for 
a long time, and there have been other solutions (Trove, GS-Collections) 
that provide 80% of the value of primitive-specialized collections for 
like 1% of the work.  But value types tip the balance from "unpleasant 
but tolerable with grumbling" to "unacceptable."

Zooming back, though, I think what you're really saying is: the part 
where List<int> is not a subtype of List is really the part you dislike 
the most, because it lives in this weird middle ground between "all 
instantiations of List<T> have a common supertype" (Java 5 generics) and 
"no instantiations of list<T> have a common supertype" (C++).  You are 
probably OK with either all (what you've got now) or nothing (if you 
hadn't had ten years of Java generics training you on homogeneous 
translation), but what really freaks you out is this half-here, 
half-there, that forces the user to be aware that reference 
instantiations are erased and value instantiations are reified, with all 
that entails.

Is that really your concern here?

On 1/4/2015 6:00 PM, Stephen Colebourne wrote:
> The specialization document include the phrase "If we were concerned
> only about primitive instantiations, we could consider some sort of
> "tagged fixnum" approach. However, this approach essentially reverts
> to boxing for arbitrary value types, so it does not get us to our
> goal."
>
> Should we take that to indicate that if value types were taken out of
> the picture, and the only goal was to handle the existing 8 primitive
> types, that there might be a potentially simpler solution - one where
> List<int> could be a sub-type of List<Integer> without boxing?
>
> Stephen
>
>
> On 4 January 2015 at 18:40, Brian Goetz <brian.goetz at oracle.com> wrote:
>>> I know our focus in this current phase is on "Layers", but would like to
>>> educate myself further about the general background of issues with Any.
>>
>>
>> Let me correct slightly.  We're investigating "layers" or "conditional
>> methods" not because this is the feature we went looking for, but because it
>> is a possible and believed-practical answer to the more general question of
>> "what generic type system can provide us the gradual migration compatibility
>> we are looking for."
>>
>> This is not unlike what happened in 8; we didn't do default methods because
>> we wanted multiple inheritance of behavior; we did it because we needed
>> *interface evolution*, and of the dozen or so possible ways to get there
>> that we evaluated, this one had the best combination of characteristics.
>>
>> So far we've gotten feedback that people don't like the balance of "user
>> model weight" and "general utility" for layers (feedback received loud and
>> clear, no need to reopen this.)
>>
>>
>> More generally, I think there's a lot of tendency to assume here that these
>> writeups constitute *decisions*, which they do not.  These writeups are
>> snapshots of where our head is at this week, which we provide so people can
>> get a peek about what we're thinking about.  But we're a long way from the
>> end of this road.
>>