<div dir="ltr"><div dir="ltr"><div dir="ltr">On Mon, Oct 21, 2024 at 4:48 AM Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" target="_blank">maurizio.cimadamore@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"><u></u>

  
  <div>
    <div><p style="margin:0px 0px 1.2em">In other words, to me
        the crux of the problem remains the definition of the loop
        induction variable. We want to carve out some special rules that
        allow us to treat the loop induction variable <i>as if</i> it
        was a variable freshly declared inside the loop body (e.g.
        meaning that the assignment we see in the STEP part of the loop
        doesn’t really affect whether that variable can be captured or
        not).</p>
      <p style="margin:0px 0px 1.2em">That seems kind of an
        orthogonal extension to the one you are proposing here - surely,
        “effectively frozen” will allow capture for far more locals (as
        your finder experiments show), but we still need to somehow be
        able to special case the treatment for loop induction variables.</p></div></div></blockquote><div>I'm saying something different from that... and also simpler.<br></div><div><br></div><div>Let's restate the conjecture: Suppose we changed the requirement for lambda capture of a variable from "final or effectively final" to "final or effectively frozen at the point of capture", where "effectively frozen at the point of capture" means there are no mutations to the variable that lexically follow the capturing lambda.<br></div><div><br></div><div>Then this would clearly subsume what's proposed in JDK-8341785 (basic for() loop variables are capturable) - it's a strict expansion of that.</div><div><br></div><div>So no special treatment of loop induction variables is needed.<br></div><div><br></div><div>Not only that, even though it's broader, it's a much simpler requirement that has no dependence on DA/DU analysis or any kind of flow analysis.<br></div><div><br></div><div>So I'm saying that this "space" interpretation - which is strictly lexical - is superior because it has all of the following nice attributes:</div><div><ul><li>It solves the original problem - allow capture of basic for() loop variables mutated only in the loop header</li><li>It also solves a much wider set of "dummy variable" cases in other code (e.g., do and while loops, and all but 5 of the METHODREF examples in the JDK)</li><li>Yet it still seems to closely match developer intuition - or at least, no less closely than the previous more limited basic for() loop proposal does<br></li><li>It is very simple to specify and understand</li></ul></div></div></div><div>The upshot is: If one were to evaluate possible replacements for the "final or effectively final" requirement for variable capture, in my opinion this would be a promising option - and in particular has a much higher cost/benefit ratio than the earlier proposal of just addressing basic for() loop variables.<br></div><div><br></div><div>-Archie</div><div><br></div><div dir="ltr"><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>
</div>