I suppose there could be an exception either for $_ or for all global variables, but wouldn’t that be overdoing it a little?

Actually, I don't think it would be over doing it. If the special case were limited to $_, that wouldn't bother me as I only use non-lexicals where the Perl forces me to, and $_ has plenty of magic associated with it anyway.

In reality, this could be viewed as the removal of an existing special case, or at leasts it limitation to a smaller range of variables that are affected by that special case.

Whilst I realise that it is unlikely to change at this point in the life of Perl5 due to the sacred cow of backwards compatibility--there is undoubtedly some code out there that relies upon the current behaviour that would break--I really do hope that it changes for Perl6.

I can't think of any other situation where an existing lexical is automagically localised?

As far as I recall, in every other language I used, the retention of the last value by non-locally scoped iterator variables is a given, and a very useful feature. I've used it a lot in parsers, where an index into a buffer is moved along it by successive for and while loops, as the buffer is deconstructed.

I guess it is slightly different in Perl's case because of the aliasing nature of iterator variables. Having two variables names pointing to the same value space outside of an aliasing construct would be a break with tradition, though if you look at the number of modules that exist to provide exactly this, it seems that it would be a useful feature in many peoples eyes.

In the end, it's only my opinion, and that isn't going to change anything, but having been bitten by the difference between my expectations and the reality several times, this is one piece of magic that doesn't DWIM for me.

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.