No. I verified that the case of for(LIST(@_)){ ... } is optimized away into for(@_){ ... } because that is what is in the original code. I also (since you just asked) tried for(@A,@B), for(@A,@B,1) and in all cases the list op was removed. Maybe the list op shows back up when there is something non-simple to read from - functions and builtins.

That's good to know, thanks.

Which version are you checking this on? And do you know if this is a recent change?

I ask because I had at least one situation where for (@array){...} definitly (seemed to?) caused a very large list to be built. At least, that's what my testing (basically watching the memory grow) showed under 5.6.1.

Update Seems I didn't keep the script, and I can't seem to reproduce the behaviour either.

I'm looking now to see if I can locate the program.

I assume that you're determining this by looking at the opcodes (as is your want:)?

---

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller

That's "wont". Its a different word. I tested this on 5.6.1 withe following programs. In all cases the list op was removed from the execution path (so named as 'ex-list'). Now from the use of pushmark I infer there's some stack muckery so maybe while list() isn't doing anything, perhaps there is some other form of listification going on here. I'm not motivated enough to break out gdb to find out.

perl -MO=Concise -e 'for(@_){print}'
perl -MO=Concise -e 'for(@A,@B){print}'
perl -MO=Concise -e 'for(@A,@B,1){print}'
[download]