On Dec 18, 2015, at 8:55 AM, Brian Goetz <[email protected]> wrote: > >> 2. It seems irresponsible to spend so much effort on >> Collections without also somehow addressing 32bit size/index >> limitations. Yes?
Yes it would be, and we are aware of this question, and expecting to address it later in the light of prior design choices. > I think that's really a separate question. While everything said so far is > Collection-specific, it's not really "so much effort on Collections" as much > as "so much effort to ensure that legacy libraries can be compatibly > anyfied", and that Collections is the poster child for that effort. (If we > can't migrate Collections, that's evidence that we're still lacking in > linguistic tools for supporting the transition to anyfied generics.) > > So I'll interpret your question as: "These are nice migration tools for > migrating erased libraries to anyfied, but there are other migrations we'd > like to perform on these aging libraries, please don't forget about them?" > > The migration in question is whether we can compatibly migrate methods like: > > get(int index) > to > get(long index) "Two instances" is always a suspected hiding place for "more than one instance". For example, an APL-like matrix can be viewed as a linear (ravel-able) collection indexed by int-pairs, which are neither ints or longs. I am assuming (until proven wrong) that the move from int to long should be part of a larger move from int to Index, where Index is an any-fied generic parameter. The practical effect of this concern, at the present moment, is that we should not only look at APIs which mention "Object" as suspects for any-fication, but also APIs which use "int" as an index. An "int" index is a candidate for replacement with some type "Index". It is *not* (IMO) likely to be a good candidate for ad hoc introduction of sibling "long" overloadings. — John
