<div dir="ltr">On Wed, Jan 25, 2023 at 12:49 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:<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>
    <font size="4"><font face="monospace">Thinking more on this -- I
        think there is significant simplicity dividend here if we relax
        our goals a little bit.  Supporting constructs such as<br>
      </font></font><br>
    <font size="4"><font face="monospace"><font size="4"><font face="monospace">        if (bar) <br>
                        this(f(bar));<br>
                    else<br>
                        this(g(bar), 0);<br>
            <br>
            would require a full DA/DU analysis, but if the goal is
            really "allow statements before the this/super", we can get
            by with a considerably simpler feature.  <br></font></font></font></font></div></blockquote><div><br></div><div>Ugh - to be honest I really don't like this simplification. For example, it invalidates two of the five "housekeeping" examples in the current JEP draft ("choosing constructor at runtime" and "complex preparation").</div><div><br></div><div>The idea of superclass initialization working just like blank final field initialization is familiar and intuitive... and the implementation is straightforward to piggy-back on existing DU/DA dataflow analysis.</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><font size="4"><font face="monospace"><font size="4"><font face="monospace">This brings the spec footprint down considerably, while
            still eliminating complex/risky workarounds around "super
            first".  <br></font></font></font></font></div></blockquote><div><br></div></div><div class="gmail_quote">I agree that we need to think carefully about how to best update the spec. But I'm not ready to give up yet on the original plan...</div><div class="gmail_quote"><br></div><div class="gmail_quote">Put another way, if a reasonable language change is such a problem for the spec, then that's a problem to solve with the spec, not the language.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Now I'm not a spec expert (it seems kind of analogous to being a patent lawyer) but what about this plan:</div><div class="gmail_quote"><ol><li>"Piggy-back" superclass initialization DA/DU on top of the existing spec for blank final fields - however you want to word that...</li><li>Specify that for any statement in a constructor:</li><ol><li>If:<br></li><ol><li>Superclass initialization is not DA at the beginning of the statement</li><li>The statement would not be legal in a static context</li></ol></ol><ol><li>Then:</li><ol><li>The statement is illegal, unless:</li><ol><li>The statement is an assignment statement and the LHS of the statement is a non-static field of the new instance<br></li></ol></ol></ol></ol></div><div>-Archie</div><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>