Personally, I wouldn't break out on a condition related to the value of $i itself in such a loop, but I often run across circumstances such that I want to use the loop variable to store the last condition that was valid, when looping through a list of valid or invalid conditions. For example,

my $condNum = 0;
for $condNum ( 1 .. 10 ) {
    forceSituation( $conditions[condNum] );
    my $result = measureSituation();
    push @results, $result;
    last if $result->is_error();
    more_manipulation(); # possibly do more stuff for this condition, 
+but only if it's not an error
}
datalog( value => $condNum, llim => 9.9, hlim => 10.1, name => 'number
+ of situations tested' );
datalog( value => fn(@results), llim => -2.7182818, hlim => 3.1415926,
+ name => 'result of those situations' )
[download]

my $lastCondNum = 0;
for my $condNum ( 1 .. 10 ) {
    ...
    $lastCondNum=$condNum, last     if $result->is_error()
    ...
}
...
[download]

(In these situations, I'm generally in a hardware-specific language, not Perl, so that one annoyance of Perl doesn't usually affect me. But there are a plethora in the hardware-specific language that I wish it did more like Perl does, so not a fair balance, in my opinion. :-( )

my $condNum = 0;
for $condNum ( 1 .. 10 ) {
    forceSituation( $conditions[condNum] );
    my $result = measureSituation();
    ...;
    last if $result->is_error();
    ...
}
datalog( value => $condNum, ...);
...
[download]

But in that case, why not use a C-style loop

c:\@Work\Perl\monks>perl -wMstrict -le
"use constant N_MAX => 10;
 ;;
 my $nCond;
 ;;
 CONDITION:
 for ($nCond = 1;  $nCond <= N_MAX;  ++$nCond) {
   print $nCond;
   last CONDITION if $nCond >= 3;
   }
 ;;
 print qq{only made it to condition $nCond} if $nCond < N_MAX;
"
1
2
3
only made it to condition 3
[download]

(as suggested here)?

---

Give a man a fish:  <%-{-{-{-<

++. I do not deny that there are multiple of fully-functional ways around the issue, and seeing so many of the TIMTOWTDI is one of the many things that draws me to PM, even though the vast bulk of my programming is not in Perl. I was pointing this out as a reasonable circumstance in which one might expect the loop variable to persist. And, like morgon expressed, it is counter-intuitive to me that my $nCond; for $nCond (1 .. 10) and my $nCond; for($nCond=1; $nCond<=10; ++$nCond) would behave differently w/r/t localization of $nCond. But every language has it's own unique character, and that's fine.

If I needed this construct in Perl, I would have eventually settled either on my alternative or this more c-like one... But likely my own alternative: over the last couple years of regularly participating here, my mindset has changed from c-like for-loops to perlish ones, so the c-for idiom is no longer my first (or often even second) choice. And, once I was reminded of the auto-localization in foreach(), I probably would have assumed auto-localization in for(;;), and wouldn't've even tried it.

Okay, you make a good case. I can see that as being useful. But to my mind the loop is the scope and the for statement is the loop definition and therefore its scope. I've never felt/noticed the lack you highlight.

I find it odd that I don't remember ever suffering from this need. I'm sure I've done something similar, but perhaps I've unconsciously soaked up that lesson long ago, and just "know" to use a second variable, or even a while loop.

-QM
--
Quantum Mechanics: The dreams stuff is made of

Probably making the (undeclared) loop $i a syntax error would be best but it looks like the ship has sailed.

Maybe so, but perlcritic spots it just fine:

$ perlcritic 1212245.pl 
Loop iterator is not lexical at line 5, column 1.  See page 108 of PBP
+.  (Severity: 5)
[download]