EG meeting, 2022-08-10

[Remi Forax]

----- Original Message -----
> From: "daniel smith" <daniel.smith at oracle.com>
> To: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Sent: Wednesday, August 10, 2022 5:46:05 AM
> Subject: EG meeting, 2022-08-10

> EG Zoom meeting August 10 at 4pm UTC (9am PDT, 12pm EDT).
> 
> Lots of recent threads that could be further discussed:
> 
> - "Question about universal type variables": Kevin started a discussion about
> how type variable types should be modeled, and what changes when they become
> universal
> 
> - "Updated SoV, take 3": Brian revised the State of Valhalla document to reflect
> recent design ideas
> 
> - "object sameness, Lebniz's Law, ...": John elaborated on SoV review comments
> regarding value object equality/substitutability
> 
> - "The storage hint model": Remi shared thoughts about using a storage
> attribute, rather than a value type, to encode flatness
> 
> - "The problem with encapsulating C.val + autoboxing": Remi discussed the
> treatment of access-restricted value types in generics
> 
> - "where are all the objects?": John and Kevin discussed usages of the terms
> "object" and "instance"
> 
> - "one class, two types, many bikesheds": John discussed how we model classes
> vs. types, the relationship of ref and val types, and how syntax like .ref and
> .val might be used
> 
> - "Value type companions, encapsulated": John shared a document describing how
> access restrictions could be enforced on value types
> 
> - "races on flat values": John discussed how the memory model needs to be
> updated to describe concurrent accesses of flat variables

Sadly, i will not be available.

I think that most of the arguments of Brian about T not being nullable by default could be applied to value type too (as an exercise, replace T by value type when re-reading Brian's email).
For me, it seems that either we go with value type being nullable by default and T being nullable by default or we don't for both.

If we choose that both value types and type variables are nullable by default, then we are very close to the storage hint model (it's a List of Integer but at runtime it uses an array of ints).
I think the storage hint model is far simpler than the Q-type model, it means less change for the VM at the price of paying a lightweight box price each time we cross an inlining horizon (sorry John).

I really do not like the idea of a private companion type, it introduces a strong couple between value type and universal generics and i do not like any of the options proposed by John to implement it.

regards,
Rémi