<div dir="ltr"><div dir="ltr">On Wed, Jan 25, 2023 at 1:23 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:</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>Not sure what you mean; the spec is the language, and the language
    is the spec.  Many things that seem simple when describing them in
    terms of "use DA/DU to ..." or "use inference to ..." turn out to be
    complicated to specify -- which means the language changes are more
    complicated than they first seemed.  Gauging the spec impact is how
    we keep ourselves honest about the scope of language changes.  <br></div></blockquote> <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>
    This is obviously doable, but my recent comments (having looked at
    what the spec impact would be) is saying that this is a more
    complicated, more invasive language feature than the simpler
    "statements before super" feature.  Part of what I'm trying to do
    here is steer towards success by pruning the problem to one that can
    be achieved without spending years immersing yourself in
    specification.<br></div></blockquote><div><div class="gmail_quote"><div><br></div><div>Fair enough...</div><div><br></div><div>I
 guess what I meant is that I'm surprised by the notion that this change
 would present a major problem in terms of updating the spec. 
The changes we want to make are clear (at least, they seem reasonably clear for this point in the process) so it's 
just a matter of articulating them precisely and unambiguously. Yes, I'm sure this will be tedious, but it shouldn't be overwhelmingly difficult. Heck if you point me at the JLS source code, I'll be happy to take a novice stab at it.<br></div><div><br></div><div>For sure, all things being equal, a simpler language change means a simpler task updating the spec. But I'd still like to better understand how it might be possible to achieve the original goal.</div><div><br></div><div>To that end, what are the problems with the plan outlined in the previous email?<br></div><div><font size="4"><font face="monospace"><br></font></font></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">
        Similarly, you'll need a way to restate the "if it doesn't start
        with `this/super`, you get an implicit super" to the more
        flexible notion being outlined here.  This is tricky because the
        obvious way to do this is to run DA/DU on the explicit body of
        the constructor and ask if `this` is DA at all points where the
        constructor could complete normally, and if not, prepend a
        super() call and rerun DA/DU.  This moves us from a strictly
        syntactic rule to one that appeals to a complex analysis.  </font></font></div></blockquote><div><br></div><div>I'm not completely understanding this. Wouldn't it be simpler to just say that for any constructor in which this()/super() nowhere appears, the analysis starts with `this` being DA instead of DU? Or equivalently, the analysis proceeds as if super() were inserted as the first statement in the constructor.<br></div><div><br></div><div>Thanks,</div><div>-Archie<br></div></div></div></div><br>-- <br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>