<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Hi, here are my two cents after following the discussions. I
personally find the limitation a little bit annoying. In my
experience, most other languages (JS, Python, C++, Rust, ...)
allow to capture (non-final) variables in lambdas. At least Java
is the only language where I have noticed this limitation so far.
However, I also don't find this limitation too bothersome.<br>
</p>
<p>
<blockquote type="cite">I think Ron has captured the stewardship
argument about how we would like users to view the language:
that the two sorts of loops, assuming each are "well behaved",
should be interchangeable, refactorable to each other, etc, and
that the differences in scoping should be an "implementation
detail."</blockquote>
</p>
<p>I think it is hard to explain that we may consider the variable
of an old-style <font face="monospace">for</font>-loop to be
scoped to the individual iteration. Consider the behavior of the
following code:</p>
<blockquote>
<pre>for (int i = 0; i < 4; i++) {
if (...) {
i += 1;
}
}
</pre>
</blockquote>
<p>Changes on the variable made inside the body will affect future
iterations. In other words, you would than need to explain that
actually, the scope of the variable depends on whether the
variable is modified within the body. I think you are better off
just explaining that there is a special case implemented for
allowing capturing variables of old-style <font face="monospace">for</font>-loops.</p>
<blockquote type="cite" cite="mid:02437772-e867-46b6-93d0-0e37beb7cd0b@oracle.com">
<blockquote type="cite" cite="mid:3ACF4EBB-F749-4887-B005-7EA20A355099@oracle.com">
<pre class="moz-quote-pre" wrap="">I also think the feature will be enjoyed far more than “20 or 30” times, or whatever corpus analysis tells us. Corpus analysis by definition measures the way people have used the language in the past, and that is often affected by their avoidance of sharp corners in the language. I believe this little polish of a central syntax in Java will affect the way people shape their code in the future. At least, it will for me, because I know I’ve done extra work to avoid the sharp corner in the past.</pre>
</blockquote>
<p>Here I don't think I agree. It's not like developers are
avoiding loop because the capture rules are what they are. If
you need a loop, you need a loop. Maybe they are avoiding
capturing lambdas - but again, replaced with what? Anonymous
inner classes will have similar issues. And if you need capture
you need capture - you can't make that go away. Perhaps they are
disguising the capture a little harder, by using an array, or an
AtomicXYZ. But I'd say that, while the numbers we have seen
might surely underestimate things a bit, I don't expect to see
dramatic differences in the wild.</p>
</blockquote>
<p>I would estimate that in 80 % of cases where I encountered the
limitation, I ended up to refactor the code by either introducing
an Iterable, so that I can use an enhanced for-loop, by extracting
the content of the loop into a separate method, or by replacing
the lambda with a named class. However, I think in a noticeable
amount of cases, the code also got more readable after spending
the additional time.</p>
<p>At the end, I find the proposal which is special-cased to the <font face="monospace">for</font>-loop a bit strange. While I wouldn't
have a problem with it, I think it would always stay a feature
specifically implemented for this style of loops. I don't think
that you can explain it away. Also, as it has been shown earlier
in the discussion, this solution would elevate the pain for not
even half of the affected cases. I think that Java should remove
the limitation in even more cases (as was proposed earlier), or
focus on making enhanced <font face="monospace">for</font>-loops
more usable (for example by providing ranges). Note that in my
experience, many languages (e.g. the same as mentioned at the
start of this email) seem to put much more focus on making the
enhanced for-loop the default.<br>
</p>
</body>
</html>