saintmike,
I have been meaning to reply to this node but I kept getting distracted.

Argument handling is one of those deceptively difficult things to do right. If you assume that your well documented API is being followed, you can probably get away with a few lines of code as you demonstrate here. The difficulty arises when you decide to handle input you don't expect. Imagine how your code would break if an uneven number of elements were passed. It can be easily remedied.

croak "Incorrect number of parameters" if @_ % 2;
[download]

Of course this is only one kind of issue that may need to be handled. There are a myriad of potential smoking guns.

• required, optional, and positional arguments
• arguments with a constraint on possible values
• argument a or b, but not both a & b can be present
• if argument a is present, argument b must also be present
• argument a's possible values depends on some other argument
• arguments that expect the value to be a specific data type

This is by far not an exhaustive list. As you can see, this can be a daunting task. That is one reason why there are a plethora of modules on CPAN. Another reason is there are many schools of thought on how to handle the issues.

There is nothing wrong with the solution you presented but it ends up producing the same underlying data structure that the Anonymous Monk indicates is undesired. I find it suspicious that there is no reason given why the obvious solution key => [$val1, $val2, $val3] is unwanted.

In any account, I wanted to take this opportunity to shed some light on the complexity of this seemingly simple problem.