|Pathologically Eclectic Rubbish Lister|
By the code working I expect that the for loops over the entire array contents including the elements added in the loop body. The expected output of this code is
abcdefWhich is in fact what I get when I run it. By safe I mean it doesn't crash or do something else unexpected when I run it. I added use strict and use warnings and the code still worked fine. No warnings emitted, no strictness violations. I'm not sure what kind of sanity checks you might add to this code. I suppose you could check at the end of the loop that the array had exactly the expected six elements in it.
It is clear to me that this technique used incorrectly could lead to creation of an infinite loop, but that is just a programmer/algorithmic GIGO type issue.
Yes, you can argue that it is unsafe because a user could accidentally write their algorithm in such a way that some data causes it too loop infinitely. But that's not the kind of safe I'm asking about. By safe I mean this. If I write a piece of code using this pattern and it works as I expected in this version of perl, is it likely to break unexpectedly when I run the same code on a different version of perl, because the fact of it working as expected depended on an implementation detail of the interpreter rather than a supported feature of the interpreter.
Or to restate the original question. The following behavior works in Perl 5.10.0 (linux/multi threaded): a for loop using an array as the sole element of its loop list can loop over the entire array even if that array is extended inside the loop body -- so the definition of 'entire' changes as the loop is executed and the array gets longer. Is this behavior a supported feature of the language which can be relied upon to work generally across future versions of perl or is it an implementation detail subject to unexpected and undocumented change?
"If God had meant for us to think for ourselves he would have given us brains. Oh, wait..."