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" <[email protected]>
> À: "valhalla-spec-experts" <[email protected]>
> 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
