Design notes for next values iteration

[Remi Forax]

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" <forax at univ-mlv.fr>
> À: "daniel smith" <daniel.smith at oracle.com>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at 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.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