Re^2: messing with @_

[polettix]

I'm not particularly fond of using split in scalar context, in a general habit of avoiding anything that complains. Anyway, the behaviour seemed interesting.

After reading the warning, I did look at the docs:

In scalar context, returns the number of fields found and splits into the @_ array. Use of split in scalar context is deprecated, however, because it clobbers your subroutine arguments.

Now, what's probably not particularly clear here is what clobbering stands for. The most natural interpretation seems (for me, of course!) to be "assigns something to your argument list, so it won't be the same any more", which is what seems to happen at the very first call to split. What I find surprising is that subsequent calls seem to imply a more general form of "clobbering", i.e. completely messing @_ contents. Given these two different "clobbering" flavours, I was wondering if it wasn't the time to promote the warning to an error.

I don't fully catch the consideration about "action-at-a-distance". If I catch my parameters at the very beginning:

sub foo {
   my ($bar, @baz) = @_;
   #...
}

I'd say that the warning doesn't apply, and I wouldn't see many problems in using @_ for other purposes, much like $_ is used for scalars. Apart, of course, that the behaviour isn't predictable here, so it has no use.

The bottom line is that my understanding of "clobbering" was quite poor here. So I'd like to understand if "clobber" expresses this "completely messing up @_ contents, which aren't reliable any more and should not be considered" or not. Anyway, the fourth example shows that @_ can't even be used any more, so there seems to be space for an error more than a warning. But this is the main reason why I'm a SOPW :)

[Fletch]

It's action-at-a-distance in that given the statement my $foo = split( /;/, $bar ); you haven't mentioned @_ at all and yet @_ will be modified. I can see the case for an analogy with $_, but in the cases where $_ is used as a default argument (and @_ is used similarly only for push pop shift unshift that I can recall off hand) you don't specify any argument and $_ (or @_) is what's mucked with. In the example I give @_ is never mentioned but there is an explicit argument passed ($bar). That's what I mean by action-at-a-distance; I mentioned another variable explicitly and yet @_ is altered implicitly.

Again, I don't think it's really an error in general since it works fine save for this corner case. But I definitely wouldn't blink twice at a documentation patch adding an explicit warning about this corner case (again analogous to the warning against modifying the variable in a for loop in perlsyn). While the for case isn't destructive per se, the behavior is undefined for both and should be avoided because you can't depend on what it's going to do (just as you can't depend on what splitting in scalar context from an element of @_ is going to do). And on the third hand I also wouldn't think it worthless to maybe forward your test case on to p5p and see if anyone there thinks the bad behavior is worth looking deeper in.

I still think it's mostly a "Doctor! Doctor! It hurts when I do this!"/"Well, don't do that." situation. Don't exercise the corner case and there's no problems.

Update: minor edit and added note about running past p5p.