messing with @_

[polettix]

Note: this has been written with 5.8.8 in mind, I don't know if it applies to other versions as well

Some days ago one guy dropped in an otherwise sleepy #perl.it and asked why something like this wasn't working properly:

#!/usr/bin/perl

bu("a:b:c:d");

sub bu {
   local $" = '], [';

   print "scalar: ", scalar(split(/:/, $_[0])), "\n";
   print scalar(@_), "[@_]\n";
   print "scalar: ", scalar(split(/:/, $_[0])), "\n";
   print scalar(@_), "[@_]\n";
   print "scalar: ", scalar(split(/:/, $_[0])), "\n";
   print scalar(@_), "[@_]\n";
} ## end sub bu
__END__
scalar: 4
4[a], [b], [c], [d]
scalar: 1
1[@]
scalar: 1
1[�]

What's that junk?

My first thougth was to turn warnings on to see what was happening, and something popped out indeed:

Use of implicit split to @_ is deprecated at ksose2.pl line 8.
Use of implicit split to @_ is deprecated at ksose2.pl line 10.
Use of implicit split to @_ is deprecated at ksose2.pl line 12.

(k`sOSe is the nickname of the guy, BTW.)

Oh wow, that split isn't doing its work nicely. Now the problem is, deprecation doesn't mean that something is forbidden, only that it should be avoided because it could be eliminated sometime in the future. Having junk in @_ is more likely a flag of "don't you dare to use this, otherwise Bad Things(TM) will happen".

I tried to concoct a couple of tests, and here's what I saw.

#!/usr/bin/perl
use strict;
use warnings;

sub first {
   local $" = '], [';
   print "first\n";

   print "scalar: ", scalar(split(/:/, $_[0])), "\n";
   print scalar(@_), " item(s): [@_]\n";
   print "scalar: ", scalar(split(/:/, $_[0])), "\n";
   print scalar(@_), " item(s): [@_]\n";
   print "scalar: ", scalar(split(/:/, $_[0])), "\n";
   print scalar(@_), " item(s): [@_]\n";
}

sub second {
   local $" = '], [';
   my $x;
   print "second\n";

   $x = shift;
   print "scalar: ", scalar(split(/:/, $x)), "\n";
   print scalar(@_), " item(s): [@_]\n";
   $x = shift;
   print "scalar: ", scalar(split(/:/, $x)), "\n";
   print scalar(@_), " item(s): [@_]\n";
   $x = shift;
   print "scalar: ", scalar(split(/:/, $x)), "\n";
   print scalar(@_), " item(s): [@_]\n";
}

sub third {
   local $" = '], [';
   my $x;
   print "third\n";

   $x = shift; @_ = ($x);
   print "scalar: ", scalar(split(/:/, $_[0])), "\n";
   print scalar(@_), " item(s): [@_]\n";
   $x = shift; @_ = ($x);
   print "scalar: ", scalar(split(/:/, $_[0])), "\n";
   print scalar(@_), " item(s): [@_]\n";
   $x = shift; @_ = ($x);
   print "scalar: ", scalar(split(/:/, $_[0])), "\n";
   print scalar(@_), " item(s): [@_]\n";
}

sub fourth {
   local $" = '], [';
   my $x;
   print "fourth\n";

   print "scalar: ", scalar(split(/:/, $_[0])), "\n";
   print scalar(@_), " item(s): [@_]\n";
   $x = shift; @_ = ($x);
   print "scalar: ", scalar(split(/:/, $_[0])), "\n";
   print scalar(@_), " item(s): [@_]\n";
   $x = shift; @_ = ($x);
   print "scalar: ", scalar(split(/:/, $_[0])), "\n";
   print scalar(@_), " item(s): [@_]\n";
}

first('w:x:y:z');
second('w:x:y:z');
third('w:x:y:z');
fourth('w:x:y:z');
__END__
Use of implicit split to @_ is deprecated at ksose.pl line 9.
Use of implicit split to @_ is deprecated at ksose.pl line 11.
Use of implicit split to @_ is deprecated at ksose.pl line 13.
Use of implicit split to @_ is deprecated at ksose.pl line 23.
Use of implicit split to @_ is deprecated at ksose.pl line 26.
Use of implicit split to @_ is deprecated at ksose.pl line 29.
Use of implicit split to @_ is deprecated at ksose.pl line 39.
Use of implicit split to @_ is deprecated at ksose.pl line 42.
Use of implicit split to @_ is deprecated at ksose.pl line 45.
Use of implicit split to @_ is deprecated at ksose.pl line 54.
Use of implicit split to @_ is deprecated at ksose.pl line 57.
Use of implicit split to @_ is deprecated at ksose.pl line 60.
first
scalar: 4
4 item(s): [w], [x], [y], [z]
scalar: 1
1 item(s): [�]
scalar: 1
1 item(s): [x]
second
scalar: 4
4 item(s): [w], [x], [y], [z]
scalar: 1
1 item(s): [w]
scalar: 1
1 item(s): [w]
third
scalar: 2
2 item(s): [8�y], [z]
scalar: 1
1 item(s): [�(y]
scalar: 1
1 item(s): [��y]
fourth
scalar: 4
4 item(s): [w], [x], [y], [z]
scalar: 1
1 item(s): [0]
scalar: 1
1 item(s): [@]

Only the second sub seems to be working properly.

I suspect that the answer to "wtf is happening here" goes deep in the perl code. On the other hand, my question is simple: shouldn't this "deprecation" warning be promoted to become a full-fledged error?

Update: I tried to make the assignment to @_ explicit rather than implicit, and it all seems to go smootly in all tests. In particular, each call to split has been changed as follows:

scalar(@_ = split(/:/, $_[0]))

and the results do not show any surprise:

first
scalar: 4
4 item(s): [w], [x], [y], [z]
scalar: 1
1 item(s): [w]
scalar: 1
1 item(s): [w]
second
scalar: 4
4 item(s): [w], [x], [y], [z]
scalar: 1
1 item(s): [w]
scalar: 1
1 item(s): [w]
third
scalar: 4
4 item(s): [w], [x], [y], [z]
scalar: 1
1 item(s): [w]
scalar: 1
1 item(s): [w]
fourth
scalar: 4
4 item(s): [w], [x], [y], [z]
scalar: 1
1 item(s): [w]
scalar: 1
1 item(s): [w]

So, it seems that there's no implicit assignment to @_... only clobbering.

[Fletch]

Erm, you're calling split in scalar context which is documented to muck with @_ and are subsequently surprised when @_ doesn't behave sanely why? The deprecation is because the scalar context behavior is action-at-a-distance, not because it doesn't work.

What you're doing is akin to modifying the array you're iterating over while inside the for loop. Calling split in scalar context works fine just like for works fine, so long as you don't push either into their one weird corner case by either modifying or using the same variable they're working on.

[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.