It’s not a special case. All iterator constructs alias their iterator variable: foreach, map and grep all do.

while(<>), which is not an iterator construct in the strict sense, is the sole exception, and we already have to tell people to always local $_; before they while(<>). I’d campaign for it to be brought in line, if it were an option at this time.

Do you really want to have to write

@foo = do { local $_; map bar( $_ ), @baz };
[download]

every time you use those constructs, to be safe from accidentally trampling a caller’s $_? I have always considered this piece of magic to DWIM.

Makeshifts last the longest.

I would not change any other constructs, nor the way $_ is localised.

I would prefer it if this

my $i;
for $i ( 0 .. 10 ) {
    last if <somecondition>;
    ...
}
my $x = substr $somestring, 0, $i;
[download]

was consistant with

my $i=0;
{
    ...
    last if <somecondition>;
    $i++;
    redo;
}
my $x = substr $somestring, 0, $i;
[download]

or

$i=0; 
do{ 
    ...
    $i++ 
} until <somecondition>;
my $x = substr $somestring, 0, $i;
[download]

If you stop getting hung up on the magic of $_, which I wouldn't change anyway, I think that lexicals that automagically revert to some previous value after the programmer has explicitly modified that value is a mysterious and non-useful behaviour that definitely doesn't DWIM.

If the programmer wants that behaviour, he could still get it by using nested scopes to achieve it

my $i=42; 
for my $i (1..10){ 
    print $i; 
} 
print $i;
## gives
1 2 3 4 5 6 7 8 9 10 42
[download]

As is, the current behaviour is a special case (of a pre-existing lexical that gets automagically localised), that doesn't fit the pattern of other looping constructs (map & grep can't use lexicals as their iterator variables) and a special case that removes flexibility, adds nothing and is confusingly non-useful.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

I’m just trying to think of a rule by which this could be made consistent and non-surprising, but failing to. I suppose it would be okay to disambiguate the desired behaviour for lexicals on the presence of a my on the loop construct – but then what about globals? Should they always be aliased? I don’t like that – I’d definitely want parity here, else people are going to have to be taught about the subtlety that foreach behaves differently when given a global than when given a lexical. Maybe require foreach our $pkgvar to get aliasing for package variables? That would be strange, though, considering the actual semantics of our. And then what about $_ – do we leave it as a strange exception case?

Given that it would be so difficult to find sane semantics to support the non-aliasing behaviour, as well as that IME you want the aliasing behaviour 99.9% of the time, I think it’s clear why my preference is to just punt on this issue. I understand why you would prefer it otherwise, and I agree that it would be nice to have this behaviour, but I think there are just too many issues to untangle once you venture past the use case in your sample code.

Maybe TimToady could let this all stew for a while and come up with one of his trademark lucid decompositions, but I can’t think of anything more desirable than the current 80/20 solution.

Makeshifts last the longest.