I can't easily do my $x, $y = @_; It's valid perl. It assigns a scalar.

Only because the way you called my creates a scalar context. Try my( $x, $y ) = @_;, which creates a list context, and so produces the same result as my $x = $_[0]; my $y = $_[1];.

This works with any array or list. Check out the difference between:

 $x, $y, $z  = (2,3,4); # $x = undef, $y = undef, $z = 4
($x, $y, $z) = (2,3,4); # $x = 2,     $y = 3,     $z = 4
[download]

See, a list in scalar context will give its last element. An array in scalar context will give the number of its elements. However, if we make both sides of the assignment have list context, then elements get copied.

Um, yeah. But it doesn't prevent me from being human and making a mistake. It's harder to get it wrong w/ a progression of shifts.

But it doesn't prevent me from being human and making a mistake.

Ok, firstly, you said that you can't easily do what you wanted, not that it was easy to make a mistake.

Secondly, attempting my $x, $y = @_ with strict in place (which is best practice anyhow) produces:

Global symbol "$y" requires explicit package name
[download]

Which would be a pretty big clue to me that something was wrong (you aren't creating a lexical $y with my $x, $y). Doing the same thing with warnings turned on (another best practice) results in:

Parentheses missing around "my" list
[download]

I'd say that pretty well prevents you from making this mistake, anyhow.

<–radiant.matrix–>
A collection of thoughts and links from the minds of geeks
The Code that can be seen is not the true Code
I haven't found a problem yet that can't be solved by a well-placed trebuchet

What wrong with my $x, $y = @_? Putting perl specifics away (not worried about the syntax like whether you should say my (a,b)). More and more languages are support this kind of de-group operation.

I personally believe that for once Cop's question is legitimate, but one cannot put "Perl specifics away" since this is Perl: while avoiding a pair of parentheses may represent an occasional advantage -I for one try to avoid them all the time, if possible- in this particular case wouldn't square at all with Perl's whole syntax and semantics. Anyway, as this very thread and tons of similar ones show, Perl's current argument passing mechanism is both fascinating for the far reaching consequences it gets out of an extreme simplicity on the one hand, and awkward on the other one. This is why after some initial period of being skeptical I now cherish Perl 6's message passing. For very simple stuff I can still rely on @_ and not worry at all. Suppose I want to write a sub that will take a list (of strings) and concat it after making all lowercase every element out of two starting with the first, and all uppercase the other ones; then I'd write it like this:

pugs> sub foo { [~] map -> $a, $b { lc $a, uc $b }, @_ };
pugs> say foo <FoO bAr BaZ>;
fooBARbaz
[download]

But if I were to write a sub that would take two integers and return the product of integer numbers comprised between them, then I would write:

pugs> sub prod (int $n, int $m) { [*] $n..$m };
pugs> say prod 3, 6;
360
[download]

--
If you can't understand the incipit, then please check the IPB Campaign.