The Good Default Value

[Brian Goetz]

> I'm trying to establish that there's never anything actually *good* 
> about default initialization; that at the very best it's "harmless and 
> very slightly convenient", no more. A typing saver in exchange for bug 
> risk. Notably it's at its most harmless for nullable types, which are 
> the more likely ones to blow up outright when used uninitialized. But 
> those aren't the cases this thread is focusing on.

OK, let me zoom out.  Primitives (and B3) support implicit construction 
(with zero default values) *so that* they can be effectively represented 
in memory.  While neither C nor Java 1.0 spelled this out, there is an 
obvious cost to representing numerics with an indirection, and the 
initialization safety of null would have effectively required 
indirection.  So numerics in C and primitives in Java (and going 
forward, B3 in Java) support default initialization not because the 
default is *semantically great*, but because it's the pragmatic choice 
that gets us the memory layout we want.

I think when you say "good" wrt default values, you're speaking purely 
about programming-model considerations (i.e., convenience, readability, 
safety), and when I say "good" wrt default values, I'm speaking about 
all of those *plus* the memory layout consequences. Which explains the 
difference in conclusion -- you're saying "not terrible" and I'm saying 
"good" because it's a good overall tradeoff.  Does that track?

> I'm wondering why we shouldn't require fields of non-nullable 
> value-class types to be explicitly initialized. `Complex x = new 
> Complex(0, 0)` or `Complex x = new Complex()`. I'll stipulate "people 
> would grumble" as self-evident.

For B1!/B2! fields, this almost a forced move, as otherwise an object 
will be created with ! fields that have null in them.  For B3! fields, 
given that the whole distinction between B3 and B2 is about implicit 
construction, this seems like it might be counterproductive, and it will 
be another seam between primitives and B3!.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20230602/8e6cc693/attachment-0001.htm>