Hum, may i should have start with that, the part that is weak in the spec IMO is the relation between a L type and its corresponding Q type.
If a Q type is a subtype of the corresponding L type, it means that one can call a method that takes a L type in parameter with a Q type as argument, but it doesn't work for the return type, if a return type is a L type, it can not be assigned to a Q type (BTW, for the same reason why in the JLS we have auto-boxing/unboxing an not only one side). So converting a class like Optional to a value type is not backward compatible. The only possible way in my opinion is if the R Optional and Q Optional occupy the same lattice, i.e. are a L Optional. This is what i have wanted to say with my first paragraph below. Rémi ----- Mail original ----- > De: "Remi Forax" <fo...@univ-mlv.fr> > À: "daniel smith" <daniel.sm...@oracle.com> > Cc: "valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net> > Envoyé: Mercredi 22 Novembre 2017 10:42:36 > Objet: Re: Design notes for next values iteration > Interesting ! > here is my current view of the problem. > > Lets say we are in the R/Q/U world, we want U interface to abstract over a > reference type or a value type, we want UObject because object is basically an > interface, we also want U object like UOptional to be able to painlessly move > a > reference type to a value type and vice-versa (no bridge-o-matic). > > But why we want Q type BTW, we want Q type because > 1/ you can not apply the same opcodes on Q types and R types (more or less, > some > ops are not defined on Q types) > 2/ we want the VM to flatten array and not box Q type. > 3/ the VM need a clean separation between Q type and R type > > For 1/ we can extends the semantics of the opcodes that only works on R types > to > work on Q types, we need that anyway for U types and at worst a valid > semantics > is to throw an exception > For 2/ even if we sak for flatten array or no box, there are case where the VM > will not flatten the array or the q type, so it's like a hint than a strict > requirement. > For 3/ the current prototype has shown that the VM is able to box/buffer value > types where needed, so no ! > > I think we do not need Q types, Q types are use site annotations, and here we > want declaration site annotations (let say that this class is a value class, > the ACC_VALUE). > > If we have no Q type, it means that R types and U types are the same thing, > everything is a U type. In term of migration, it means that L types need to > have their semantics extended to work as U types. > > Obviously, the devil is in the details, but i think from the VM POV, we should > extends L types to behave like U types. > From Java the language POV, we may want to not compile when a variable is > typed > with value type is assigned to null, same with generics, you may want to > declare a type variable any but from the VM POV, this should be possible and > either throw an exception, return false, etc. > > Let's make the VM powerful and let's Java the language helps users to not have > too many exceptions. > > regards, > Rémi > > ----- Mail original ----- >> De: "daniel smith" <daniel.sm...@oracle.com> >> À: "valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net> >> Envoyé: Mercredi 22 Novembre 2017 06:54:55 >> Objet: Design notes for next values iteration > >> Following up on John's mail, here are some detailed notes about the design >> choices for "U types", and the concrete proposal we settled on last week. >> >> http://cr.openjdk.java.net/~dlsmith/values-notes.html >> >> John may have raised additional points I didn't cover in this document. I'll >> do >> another review of his mail and make any needed updates; or feel free to call >> them out. :-) >> > > —Dan
