> When calling a sub that has both named params and a slurpy list, the
> slurpy list should always come last. If a sub has both a slurpy hash
> and a slurpy list, the slurpy list should still always come last. You
> simply can't credibly have anything after the slurpy list, or it'll be
> slurped. So args/params must ALWAYS come in this exact order, if they
> are to be useful:
>
> sub foo(
> $x, # required positional
> ?$y, # optional positional
> +$k, # optional named
> *%h, # optional slurpy hash
> *$s, # optional slurpy scalar
> [EMAIL PROTECTED], # optional slurpy array
> ) {...}
>
> I guess what I'm not understanding is why you would _EVER_ want [EMAIL PROTECTED]
> to be in the named-only zone, and presuming you never would, why we
> can't syntactically / semantically fix the above gotcha so that the
> params always appear in the "calling" order?
The idea is that positional parameters are always a contiguous
sequence in the argument list. If it looked like this:
sub foo($x, ?$y, +$k, [EMAIL PROTECTED]) {...}
Then one might presume to call it like:
foo($x, $y, $k, 1, 2, 3);
Which they can't. So it makes sense to have everything positional up
front, while things that can go anywhere (but must be labeled) in the
back.
Your method makes sense, too. To me, they both make a lot of sense,
but they aren't orthogonal. So you have to pick one. I'm happy with
the current way.
Luke
