<div dir="ltr"><div dir="ltr">On Thu, Jun 1, 2023 at 3:42 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:<br></div><div dir="ltr"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>Another way to think about this is the historical progression. <br>
<br>
In hardware / assembly language, when you load a value from a
register or memory location, and you haven't provably put a good
value there, you get an out-of-thin-air value. There is no "safe
initialization" of anything; there is just memory and registers. <br>
<br>
C more or less propagates this approach; if you don't initialize a
variable, you get what you get. C doesn't force indirections on
you; you have to ask for them. <br>
<br>
Java 1.0 moved the ball forward for direct storage, saying that the
initial value of any heap variable is zero, and requires that locals
be initialized before use. It also moves the ball forward by
putting indirections in for you where they are semantically needed.
But Java copies what C did for primitives; in the desire to not make
arithmetic ungodly expensive, an int is just a direct machine int,
like in C, with a frosting of bzero. <br>
<br>
Valhalla gives us a choice: we can flatten more non-nullable things,
or we can cheapen (somewhat) the things that use null as a
initialization guard. The good thing is that we can choose which we
want as the situation warrants; the bad thing is we can make bad
choices. <br>
<br>
People will surely make bad choices to get the flattening benefits
of B3, because, performance! But this is not all that different
from the other bad performance-overrotations that people make in
Java every day, other than this one is new and so people will
initially fall into it more. </div></blockquote><div><br></div><div>I'm not necessarily following the impact of these statements on the arguments I'm making. I don't think I'm raising concerns about people picking the wrong bucket.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><blockquote type="cite"><div dir="ltr"><div class="gmail_quote">As far as I know, Valhalla could
*maybe* still decide to require that non-nullable variables of
value-class types be initialized explicitly. Maybe it would
complicate migration too much, I'm not sure. I know it would
require one new feature:<br>
<div><br>
</div>
<div>`new ValClass[100] (int i -> something())` <br>
</div>
</div>
</div>
</blockquote>
For fields, we can close the gap by doing null checks at constructor
end (in the same place we emit memory barriers to support the final
field initialization safety guarantees.) The latter is voided when
`this` escapes construction, and the former would be as well, but
this seems a pragmatic choice which narrows the initially-null
problem quite a bit for fields.</div></blockquote><div><br></div><div>I do like that, but again I think it's addressing a different set of issues than I'm trying to. My brain is certainly fuzzy, though.</div><div><br></div><div>Again I'd say that initialization problems that leave something *null* are probably the least-harmful kind, thanks to our beloved friend NullPointerException.</div><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>As you point out, arrays are
harder, and it requires something much like what you suggest (which
is also a useful feature in its own right.) Note that none of this
is needed for B3!, only for B1!/B2!. </div></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div> . . .<br>
Nothing wrong with `new B3![n]`, any more than `new int[n]`. It's
B1/B2 that have the problem. <br></div></blockquote><div><br></div><div>I think I *am* talking about B3? If you could reread my message it might help. Or you might just tell me to reread yours (which I would). :-)</div><div><br></div><div><br></div><div><br></div></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div style="line-height:1.5em;padding-top:10px;margin-top:10px;color:rgb(85,85,85);font-family:sans-serif"><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Kevin Bourrillion |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px"> Java/Kotlin Ecosystem Team |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px"> Google, Inc. |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px"> <a href="mailto:kevinb@google.com" target="_blank">kevinb@google.com</a></span></div></div></div></div></div></div></div></div>