...My concern is that given an argument supplied as a pair (foo => "bar"), it is not clear which type of parameter is meant to be supplied. If there is no such named parameter, we know that the argument was intended for the slurpy hash. However, what if the method designer later adds an optional parameter, often to be implemented as a named-only parameter +$foo?
I have thought a bit about possible fixes, and while there are many possible, I think the best approach would be to separate the related but distinct concepts of supplying an argument to a named parameter from the general Perl 6 notion of a Pair.
The problem is, if we supply a different syntax for named parameters, sooner or later somebody's going to want to have the equivalent of a slurpy hash for them. And then we'll have exactly the same ambiguity, except we'll have added even more syntax to a language that's already large and complex.
Perl 6 will supply type checking to catch this sort of error, and module versioning to make it easy to work around. Beyond that, module designers who use slurpy hashes will simply have to keep in mind that they need to validate any named parameters they add in later versions.
-- Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker
Oceania has always been at war with Eastasia.
