<div dir="ltr"><div dir="ltr">On Wed, Jan 25, 2023 at 2:19 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:</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><br><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><div><div class="gmail_quote"><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>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    For example, here's a constructor that contains a `this()` call, but
    for which `this` is not DA at the end:<br>
    <br>
    C() { <br>
        if (foo) <br>
            this(3);<br>
    }<br>
    <br>
    As it turns out, there's nothing we can do to save this constructor;
    we're going to error out due to flow issues.  But we have to do a
    fair amount of work before we can figure that out.  But the mere
    syntactic presence or absence of a super/this call is not obviously
    sufficient.<br>
    <br>
    The current rule about implicit supers is _syntactic_; we need only
    look at the parse tree and ask "was there an explicit super call",
    and know immediately whether we have to treat things as if there
    were a synthetic one, or not, before doing any analysis.  But a
    DA/DU-based rule means we have to speculatively perform linguistic
    analysis on the code (type checking, flow analysis, etc) to even
    determine whether this is really the code we want to work with in
    the first place, or whether we have to mangle it and then do it all
    again.  (Even this description is more a description of what the
    compiler will do; the spec doesn't talk about processing or type
    checking as a thing that happens, and so leans more heavily on
    things happening in a certain order in order for such analysis to be
    well-defined.)  <br></div></blockquote><div><br></div><div>I'm still not understanding (sorry).</div><div><br></div><div>The new rule for implicit supers would be syntactic as well.</div><div><br></div><div>The rule is this: Add an implicit super() if there are NO occurrences of any this() or a super() anywhere in the constructor.</div><div><br></div><div>This is just the direct generalization of the previous version of this rule.<br></div><div><br></div><div>If there is a this()/super() on some code branch but not on another, then do nothing. The DA/DU analysis will automatically catch the error.<br></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>
    Additionally, since we currently quarantine the cases where `this`
    is DU to the single explicit constructor call, we don't have to
    thread DA of `this` throughout the rest of the JLS; the
    generalization would likely send tentacles farther and wider (e.g.,
    lambda bodies, switch expressions, etc.)  <br></div></blockquote><div><br></div><div>This is where I'm proposing that we borrow from the concept of "static context". We'd say the "static context" rules apply to any statement in a constructor where 'this' is DU, with the exception of field assignment. This rule would just be an additional condition added on top of the existing rules. Wouldn't that work?<br></div></div><div><br></div><div>-Archie<br></div><br>-- <br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>