On 30 Jun 2023, at 18:38, Brian Goetz wrote: …
>> Here is a complementary principle: In the VM, we should choose to support >> exactly and only those refinement types that support Valhalla’s prime goals, >> which are data structure improvement (flattening). Since |String!| doesn’t >> (yet) have a flattening story, |String!| should not be a (VM) representable >> type. >> > > I'd agree, but only if I can add "yet". Good! There was a “yet” in there, and I meant yet another “yet”. (It was a silent “yet”.) … > Spoiler: I much prefer to check on write, and ultimately, push that check > into the VM using the same value set restriction machinery as we do for B3!. (I teed that up for you. You might be right.) >> I don’t think there is a rift-healing move we could do with field >> declarations, since flat |int| fields are already fully supported. >> > > We could be generous in linkage, treating "I" and "LInteger;" with a type > restriction as the same type, but it doesn't seem worth it. Yes! >> Although it is technically an incompatibility, we might consider >> allowing legacy |int[]| arrays to interoperate with |Object[]|, >> so that more generic code can be written. That would be close to >> the spirit of allowing |B3![]| arrays be viewed transparently as >> possibly-null-tolerant |B3[]| arrays. >> > > I think we concluded that this was probably a forced move at some point, but > we should revisit that analysis. Looking at Arrays.java and ArrayList.java, and thinking about T=int in those algorithms and containers and others, made it clear the choice is between |int[] <: Object[]| or replicated bytecodes, either by hand (like we do in Arrays.java) or somehow else (circa Model-2). >> I mean that the call |int.class.cast(x)| does not work, and lifting >> that non-behavior up to |RepresentableType| will make a new and >> unwelcome distinction between |B3!| and |int|: The mirror for |B3!| >> > > (not actually a mirror) Sorta-mirror. Mirror of a different class. Mirror-oid.
