<div dir="ltr"><div dir="ltr"><div>There is one thing that I simply can never let go without comment (which Brian had to have known :-)).</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 31, 2023 at 11:37 AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>> wrote:<br></div><div dir="ltr" class="gmail_attr"><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><font size="4"><font face="monospace">### Initialization<br>
<br>
The key distinction between today's primitives and objects has
to do with<br>
_initialization requirements_. Primitives are designed to be
_used<br>
uninitialized_; if we declare a field `int count`, it is
reliably initialized to<br>
zero by the JVM before any code can access it. This initial
value is a<br>
perfectly good default, and it is not a bug to read or even
increment this field<br>
before it has been explicitly assigned a value by the program,
because it has<br>
_already_ been initialized to a known good value by the JVM.
The zero value<br>
pre-written by the JVM is not just a safety net; it is actually
part of the<br>
programming model that primitives start out life with "good
enough" defaults.<br>
This is part of what it means to be a primitive type.<br></font></font></div></blockquote><div><br></div><div>Uninitialized values of primitive types do still cause bugs.</div><div><br></div><div><div>Uninitialized values of primitive types do still cause bugs!</div></div><div><br></div><div>If it scanned better I'd put it to music.</div><div><br></div><div>I think I understand the sense in which the phrase "it is not a bug to" is intended above, but to me it's still an outrageous statement.<br></div><div><br></div><div>Put succinctly, I'm still unconvinced there is any such thing as a "good default value". What I see are varying degrees of tolerable ones. Which we tolerate why? Because performance, end of story. Oh, it might happen to be the default you wanted, but in my mind that's just coincidence (if admittedly not a very rare one).</div><div><br></div><div>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><div><br></div><div>`new ValClass[100] (int i -> something())` </div><div><br></div><div>... which, importantly, must compile to the optimal code (that never actually loops) when `something()` is literally just a call to ValClass's implicit constructor (or is otherwise the default value for the type in question). In case `(i -> MyImplicitlyConstructableType())` is the behavior you want, you'd be a bit steamed to have to write it out. But just *how* valuable is getting to skip it? I wonder.</div><div><br></div><div>And I would claim with some vigor that this array syntax would *always* have been a lovely feature to have in any case. It looks to me like it wrangles and contains the initialization gap in much the same way try-with-resources wrangles and contains the acquire-release gap.</div><div><br></div><div>Maybe this is off the table for $reasons -- but then here's my point. If it is, I claim that's a *sacrifice* we're making -- not that it was made unnecessary by the preponderance of types with so-called "good default values".</div><div><br></div><div>In other words, even if my plea here changes nothing about the feature design (after all, it is work), I still hope merely to convince us to talk about the feature differently than we have been, because I think it matters.</div><div><br></div><div>Okay. That's my highest bid. If it didn't shift anyone's view I'd really appreciate hearing the rebuttal.</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>