For loops used to have the limitation to flatten the iterated structure to a list, which resulted sometimes in unfortunate memory requirements.

IIRC this was partially fixed by parsing if it's an @array or a range-operator, and acting like an iterator (ie for (reverse 1..1e18) remained problematic, because reverse was not detected)

I'd say this is the essential hook allowing your trick of iterating an "injected" tied array.

Did I miss something?

I have to admit that I am not a specialist on the Perl internals (more precisely I do not know anything about it), so my guess is the following:

If any element of LIST is an lvalue, you can modify it by modifying VAR inside the loop. Conversely, if any element of LIST is NOT an lvalue, any attempt to modify that element will fail. In other words, the foreach loop index variable is an implicit alias for each item in the list that you're looping over.

from perlsyn means that for anything that can be modified (i.e. an lvalue) in the loop's body, Perl must remember where it is stored. When accessing or modifying it, the tie mechanism is invoked. So this version

tie @ary, "My::Class", "some", "el", "ems";
for (@ary) {
   some_code($_);
}
[download]

must have worked ever since tie exists. Using sub wrapper : lvalue {...; return @x} is only turning the result from the sub to be an lvalue (according to the docs since Perl 5.6).

Whether or not this is what is really happening I do not know.

Update: reversed lvalues seem to be fine as well:

my @arr1 = (0) x 4;
my $n = 0;
for( reverse @arr1 ) {
    $_ += $n++;
}
print "@arr1\n";

__END__
Output
3 2 1 0
[download]

Wait now I am confused...

I thought the whole spectacle is about hooking into the iterator on the arrays level.

But you are talking about the lvalue character on the elements level...

Probably I need to start reading the whole thread again ...

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}