<div dir="ltr">well, uhh, "nay" :-) <div><br></div><div>But seriously, I don't disagree that in Example A it's more than sufficiently unambiguous which value the developer wants. I just feel like this whole topic is uncomfortably intricate and messy, and the specific benefits of the change don't feel to me like they will ever be worth even the time that's <i>already</i> gone into discussing it, especially when (as Tagir said) what users really want is loops over ranges anyway.</div><div><br></div><div>To me changing nothing feels like winning here, but that's just me.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 21, 2024 at 10:00 AM Archie Cobbs <<a href="mailto:archie.cobbs@gmail.com">archie.cobbs@gmail.com</a>> wrote:<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 dir="ltr"><div dir="ltr">On Mon, Oct 21, 2024 at 11:36 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>
    <p>What I'm trying to say is that if a
      developer is confused (by the i++) on what "frozen" means for a
      loop variable, they won't find any clarity in our explanation that
      "lexically scoping trumps everything else". E.g. whether a
      developer reads the STEP part of a loop as part of the body (after
      the end of the body) or not is, I believe, a very subjective thing
      - and one which affects how any change we make in the area will be
      perceived (IMHO).</p></div></blockquote><div>Yes, if a developer is mentally cutting and pasting the STEP onto the tail of the BODY then you're right, that makes it appear as if the variable is not really "frozen".<br></div><div><br></div><div>But the original basic for() proposal has the analogous problem - i.e., if a developer is mentally cutting and pasting the STEP onto the tail of the BODY, then in the original proposal the variable no longer appears to be "effectively final in the body of the loop".</div><div><br></div><div>So it seems to me that this proposal and the original basic for() proposal suffer equally in that particular respect, and such a developer is not going to be satisfied by either of these new mental models.<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><p>Of course, as with every new proposed feature, we hear a lot from
      developers who think that the new proposal addresses a specific
      pain point that they thought should never existed in the first
      place. But we tend to hear less about a less vocal portion of
      users who might just be silently ok with the status quo. Or maybe,
      in this instance, we don't hear from them because they aren't
      there (although, Tagir expressed some concerns [1], so I have to
      assume there are such developers out there  _somewhere_ :-) )<br></p></div></blockquote><div>I too would like to hear more opinions... speak up, naysayers :)<br></div><div><br></div><div>-Archie<br></div></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>
</blockquote></div>