Replace the primitive class with a more general null safety?

[Brian Goetz]

On 12/1/2022 12:50 PM, Glavo wrote:
> Optional.val? Do you mean that the reference-favoring primitive class 
> still exists?

Not quite.

The names in the model have changed over the iterations, but the 
concepts basically have stayed the same.  Some of the classes we want to 
write with Valhalla are just "objects without identity", but are not 
really "like primitives"; LocalDateTime is an example of this.  Others 
are much closer to pure numerics, such as Complex or HalfFloat, and are 
much more "like primitives".  A key difference is that one has a natural 
zero and can therefore be used uninitialized (like int fields), whereas 
the other does not and therefore must be handled through a reference, 
whose initial value is null.  (Though we can still obtain some 
substantial optimizations even for these reference types.)  We've been 
calling these "bucket 2" (objects without identity) and "bucket 3" 
(primitive-like types), which in the more recent model were described 
with value classes and primitive classes.

Regardless of the stacking, a primitive class gives rise to TWO types, 
which I'll call P.val and P.ref here.  One is a reference type, the 
other is a value type.  These are analogous to int and Integer, and they 
have the usual array of differences: nullability, default values, direct 
vs indirect, tearing under race, etc.

A pretty clear decision that has emerged is that for both

     value class V { }
and
     primitive class P { }

the language-level types V and P are *reference types* (so P is an alias 
for P.ref in the ref/val model.)  I won't rehash the arguments in favor 
and against here, but this means any "unadorned" type is a reference 
type, regardless of whether it is an identity, value, or primitive 
class.  In this way, all primitive/value classes are "ref favoring", and 
there's no explicit way to flip this, so no need for the 
ref-default/val-default syntax of a previous round.  One of the benefits 
of this is that migration is smoother because migrating an identity 
class to either of the new buckets is source- and binary-compatible.

> For migration related matters, I don't think you need me to introduce 
> these, but I just remind you that although they are very basic,
> they often don't get the attention they deserve, thus becoming an 
> obstacle to migration.

One of the reasons Valhalla is taking so long is we take migration 
compatibility very seriously.