Design notes for next values iteration

[Remi Forax]

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.smith at oracle.com>
> À: "valhalla-spec-experts" <valhalla-spec-experts at 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