[External] : Re: Revisiting default values

[Kevin Bourrillion]

On Wed, Jun 30, 2021 at 8:40 AM Brian Goetz <brian.goetz at oracle.com> wrote:

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

We might be miscommunicating?

Just gonna be candid. This qualitative argument is both of no use,
*and* unnecessary,
because the quantitative argument is the whole point. I mean: if
feature-variation-A actually wipes out 40% of the performance benefit of
the whole endeavor, you'd hardly need to convince anyone it's a
non-starter, not even *me*. Just like if it wiped out 1% of gains (while
preventing many likely bugs) then *you* would hardly need convincing. So, I
can't figure out what your purpose in saying this is.


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

(I was treating customized-default-bits as being off the table, so I'm not
sure what this is about?)


Now, let's talk more about null.  Null is a *reference* that refers to no
> object.
>

But also: "a primitive is a predefined irreducible type!"

I sincerely claim that your statement is in the same boat. You're speaking
of what has *happened* to be the case in Java, because reasons.

However, I think the *concept* of null is more basic; it is just "there is
no instance here". Try to do instance stuff, blow up always, that's null.

If you say it's *fundamental* to the notion of a primitive/inline type that
there is *always* a value there.... okay, but then what you're talking
about is *bits*. Yep there are always bits there. But is that what matters
to software? What software wants is programs that are first correct and
then (as hot on the heels as you like) performant.

I've said that primitive types for which all-zeroes isn't *valid* would
prefer to surface that value as *null *instead. So I guess my big bold play
here is to claim that the primitive type "reference" is just the first
*example* of this category, that's all.

(I feel very untroubled by seeing "reference" as a primitive type, which is
special only in that Java traverses it for you -- lets you see "dereference
then member access" as if it is just "member access" -- which it does for
obvious and obviously-special reasons.)


... distorting what null is ...
> ... muddies what null means ...
>

One of the things I *very much* like about where this project has gotten to
is that the "ret-cons" it requires *aren't even really ret-cons*.

   - "Primitive" has always meant "inline". It never really meant
   "predefined"; Java just didn't happen to let you define them.
   - "Instance" has never really meant "thing on the heap with identity".
   It always meant "one of a class". Java just didn't happen to have other
   kinds.
   - "Null" as a noun was never well-defined, only "null literal" and "null
   reference". "null reference" has always meant "there is no instance here",
   and if we *do* define "null value", it will mean the same thing!


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

Sure, I'd be very interested in that discussion too.


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
>
> Clarifications:

* "special cases" != "rare" or "exotic"
* "dubious" != "bad" or "wrong"

Also, reminder that X% of my opinions are wrong


-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com