Larry Wall wrote:
Yeah, I agree. How 'bout we go with something like you have to *
the actual hash (if it's the first thing) to make it look like a
list of pairs to the parser, and we can just get rid of 3 there.
I'm not sure if 3) was superflous depending on the definition of "non-pair".
Did you mean none(Pair, Hash) or just none(Pair)? And is there something
like a parsed pair---I mean fat arrow in the parse tree as opposed to
an instance of Pair? How is
my Pair $p = (x => 3);
foo $p; # $x = undef, %opts = { x => 3 }
handled in comparison to
foo x => 3; # $x = 3, %opts = undef
Cases 2) and 3) actually look more like special cases of a
type check to me. And does the rule say that type errors are
shoved into the slurpy hash if present? Which would give a
nice way to implement unchecked sigs by adding an implicit
*%_ parameter? IIRC it was mentioned as a feature somewhere
to have more than one slurpy array or hash with different
types.
Regards,
--
TSa (Thomas Sandlaß)
