<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 23/10/2024 13:00, Ron Pressler
wrote:<br>
</div>
<blockquote type="cite" cite="mid:DA336424-4BFB-404F-9AAC-A006FED78A80@oracle.com">
<pre>That x really means something subtly different in the foreach loop and
the classic loop is more of an implementation detail. I don’t know the
history of that choice, and it did predate lambda, but if it was made to
allow a final index to be captured in an index class, then
capturability is the motivation for that detail.</pre>
</blockquote>
<p>I don't disagree that is a matter of perspective (I called it
subjective). As I stated:</p>
<p>
<blockquote type="cite">How you "fix" this largely depends on (a)
how you find this asymmetry annoying (which likely depends on
exposure - and different code bases might have different levels
of that) and (b) how much your developer intuition is trained to
view the loop induction variable as a single mutable *variable*,
or a series of *values* where each value is derived from the
former in a controlled fashion. I don't have a strong (enough)
opinion on either :-)</blockquote>
</p>
<p>IMHO both (a) and (b) are subjective calls. I feel that some
developers will stand by the asymmetry because for-each is
special, and doesn't use mutation (no need to do `i++`) so _of
course_ you get a "fresh" `i` on a for-each iteration (but not in
an imperative for loop). This is further reinforced by the fact
that you can add `final` on for-each variables, but not in the
imperative loop induction variables.<br>
</p>
<p>Other developers will find this distinction annoying, because in
a well-behaved counted loop, the mutation of the induction
variable is so controlled that it can largely be ignored (and be
treated as an impl detail).</p>
<p>I think both views have their own merits<br>
</p>
<p>Maurizio<br>
</p>
<p><br>
</p>
</body>
</html>