Replace the primitive class with a more general null safety?

[Remi Forax]

----- Original Message -----
> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Glavo" <zjx001202 at gmail.com>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Sent: Thursday, December 1, 2022 7:34:27 PM
> Subject: Re: Replace the primitive class with a more general null safety?

> 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.

yes, it something that can be seen clearly with the current prototype when trying to use a primitive class (old style val-default) with generics.
You can not declare a List<P>, you have to use a List<P.ref>.
Primitive classes being ref-default solve that until we get proper specialized generics.

Rémi