[External] : Re: Revisiting default values

[Brian Goetz]

Of your points, I think this is the controversial one, and it goes 
straight to "what is the point of primitive classes."

You kind of dismiss optimization, but of course a big part of the point 
is classes that are more optimizable; if we didn't care about 
optimization, we wouldn't bother with primitive classes, we'd just say 
"write classes."

The unfortunate bit is that the reason we're stuck with zeroes as the 
default value comes from the VM's desire to provide both safety _and_ 
performance.  Painting with a roller is cheaper than with a brush, but, 
more importantly, all-zeroes is the only value the JVM can really give 
while promising that some other OOTA value will never be observed, 
regardless of races and other timing hazards.

Now, let's talk more about null.  Null is a *reference* that refers to 
no object.  For a flattened/direct object (P.val), null cannot be in the 
value set (it's the wrong "kind"), though we can arrange for a primitive 
to behave like null in various ways.  It's not clear whether this helps 
or hurts the mental model, since it is distorting what null is.

Really, what this discussion is about is about whether _uninitialized 
primitive objects_ can be used or not; since T.default is a hidden 
constructor, we want to know whether that value is safe to use or 
whether it is merely a tombstone.

We can arrange that x.m NPEs when x == X.default, but that doesn't 
really mean that x is null.  It means that you've dereferenced something 
that should have been initialized before dereferencing it.

The alternative approaches are worse, since they involve creating a 
second null (see John's "No New Nulls" manifesto), which I think we can 
agree no one will like.

What worries me about this approach is that it muddies what null means, 
since a P.val is not a reference to anything.

I think we are better off treating this as a discussion about 
initialization safety, rather than nullity, until we have a clear story 
of how we want things to behave.





On 6/29/2021 1:54 PM, Kevin Bourrillion wrote:
> Among all the use cases for primitive classes, the ones where the 
> default value is non-degenerate and expected are the special cases! We 
> use `Complex` as a go-to example, but if most of what we did with 
> complex numbers was divide them by each other then even this would be 
> dubious. We'd be letting an invalid value masquerade as a valid one 
> when we'd rather it just manifest as `null` and be subject to NPEs.