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