in reply to It is weird, it is mad, but is it portable? (foreach question)

From Dominus's blog:

Perl: modifying an array in a loop

Another example is the question of what happens when you modify an array inside a loop over the array, as with:

@a = (1..3); for (@a) { print; push @a, $_ + 3 if $_ % 2 == 1; }
(This prints 12346.) The internals are simple, and the semantics are well-defined by the implementation, and straightforward, but the manual has the heebie-jeebies about it, and most of the Perl community is extremely superstitious about this, claiming that it is "entirely unpredictable". I would like to support this with a quotation from the manual, but I can't find it in the enormous and disorganized mass that is the Perl documentation.

Addendum: Tom Boutell found it. The perlsyn page says "If any part of LIST is an array, foreach will get very confused if you add or remove elements within the loop body, for example with splice. So don't do that."

The behavior, for the record, is quite straightforward: On the first iteration, the loop processes the first element in the array. On the second iteration, the loop processes the second element in the array, whatever that element is at the time the second iteration starts, whether or not that was the second element before. On the third iteration, the loop processes the third element in the array, whatever it is at that moment. And so the loop continues, terminating the first time it is called upon to process an element that is past the end of the array. We might imagine the following pseudocode:

index = 0; while (index < array.length()) { process element array[index]; index += 1; }

There is nothing subtle or difficult about this, and claims that the behavior is "entirely unpredictable" are probably superstitious confessions of ignorance and fear.

Replies are listed 'Best First'.
Re^2: It is weird, it is mad, but is it portable? (foreach question)
by moritz (Cardinal) on May 20, 2008 at 10:51 UTC
    IMHO it is foolish to rely on undocumented behaviour, even if it works with the current perl version. There's no guarantee that future implementations will do it the same way. Future implementations might implement a more iterator-like approach (for example to remove the memory panelty that for (<filehandle>){...} involves, or for other reasons).

    If somebody relies on the current behaviour, sending a doc patch to p5p is the thing to do. Once that doc patch is in a stable version of perl, you can rely on it.