Design notes for next values iteration

forax at forax at
Wed Nov 22 16:42:04 UTC 2017

----- Mail original -----
> De: "daniel smith" <daniel.smith at>
> À: "Remi Forax" <forax at>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at>
> Envoyé: Mercredi 22 Novembre 2017 16:32:36
> Objet: Re: Design notes for next values iteration

>> On Nov 22, 2017, at 2:42 AM, Remi Forax <forax at> wrote:
>> 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.
> Yeah. We discussed this and I mentioned it in the notes, but it could use a
> deeper exploration at some point.
> As a minimum, there probably needs to be *some* way to indicate that a field can
> be flattened and may not be null. If a field has a U type, the referenced class
> would have to be loaded before we could tell if it's referencing a value class
> or not, and that's costly.

The L type reference a class that is tagged with ACC_VALUE, so the VM knows if a type is a value type or not.

BTW, an array of a class which is tagged with ACC_VALUE is not necessary flatten, again the array might be too big, so it means that being flatten or not is a dynamic property, thus it should not be encoded in the VM type system as a Q-type. 

> —Dan


More information about the valhalla-spec-observers mailing list