Thoughts on peeling and readability

Brian Goetz brian.goetz at
Sat Dec 12 17:14:54 UTC 2015

Without being drawn into a "draw the line" exercise ... that's almost 
certainly on the other side of the line.

"Just specific instantiations" is a pretty compelling place to start -- 
and probably end -- because they map directly to the underlying VM type 
system.  HashMap<erased> maps to a distinct runtime type; 
HashMap<int,int> also does; HashMap<K, V extends Comparable<? super K>> 
does not. (Also, if you allow separate specializations of 
HashMap<String, any> and HashMap<any, String>, which do you use for 
HashMap<String, String>?  Now you need runtime "most specific" 
analysis.  Yech.)

Once you cross the line of "specific instantiations", now you're asking 
the runtime to redo a lot of computation that we'd like to leave in the 
static compiler.  This seems to be entering the "bad return on 
complexity" portion of the curve.

On 12/12/2015 4:29 AM, Richard Warburton wrote:
> Hi,
>     Yes, there are thoughts and plans :)  But we're focusing first on
>     the "how do I write a fully generic ArrayList" first, and then
>     we'll turn to how this could be further hand-optimized for
>     specific instantiations.
>     (It's worth noting, though, there are actually not that many
>     concrete examples.  ArrayList<boolean> is an obvious one, as is
>     HashMap<int,int> (the literature is full of optimized Map
>     implementations for this case.) And things like Optional<ref>,
>     which can have a more compact representation than Optional<int>. 
>     Beyond this, the "obvious" examples tail off pretty quickly.
> Are you able to comment on whether you plan to offer more flexible 
> specialization plans than just specific instantiations? For example is 
> providing a specialization for the generic type HashMap<K, V> where K 
> = V on the cards?
> regards,
>   Richard Warburton
> @RichardWarburto <>

More information about the valhalla-dev mailing list