<div dir="ltr"><div>On Fri, Jun 2, 2023 at 10:31 AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:<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>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_quote">
          <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>
      </div>
    </blockquote>
    <br>
    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.  <br>
    <br>
    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.</div></blockquote><div><br></div><div>I low key suspect you might have that impression mostly because it's what you *expect* from me. Or I might have communicated badly, or am missing something obvious (wouldn't be the first time today).</div><div><br></div><div>I was hypothesizing that we could have both. I've floated the idea of requiring explicit initialization, but did acknowledge that something would absolutely *have* to optimize a literal `new MyVal[1000] (i -> MyVal.default)` (handwave syntax) to the same thing `new MyVal[1000]` would do (if allowed). I wouldn't have it otherwise. I *think* that bridges this perceived gap?</div><div><br></div><div>If that's impossible, this whole thread basically goes away.</div><div><br></div><div>Now the reaction I'd *expect* is "no one wants to have to write that". But I think that actually supports my main point: that this is a convenience argument, not that that default is in any intrinsic way "good". Then I guess my secondary claim is that it's actually *mild* convenience at that. </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"><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></div></blockquote>
    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!.<br></div></blockquote><div><br></div><div>Making primitives more special is bad, it's true. But for what it's worth, from my experiences, what I'm saying does apply to primitives too: `new int[100] { 0 }` is just as superior to `new int[100]` as with the MyVal case above. The only difference (in my magic-wand universe here) is that the int case can draw only a warning, for $someLongPeriodOfTime, before the seam goes away. I think a seam with an expiration date is *already* a less-bad kind of a seam just for that fact, even if that date is *very* far in the future.</div><div><br></div><div>I realize this is a hard pill to swallow, and I can't be surprised if my full argument doesn't carry. But even given today's exact design, I have to object to the *way* it keeps being justified.</div></div><div><br></div>Did this help?<br clear="all"><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>