Erm, the list is ordered, and it's the order the keys from that list are used to initialize the hash that's important. If you're going to allow multiple occurrences of any particular key in the initializing data then you're going to have to have a rule for which one "wins" when there are duplicates.
The only sane rules are going to be "first occurrence wins" or "last occurrence wins" (either of which would allow some variant of the technique in question, so you'd do %hash = ( existing => "new value", %hash ) in bizzaro-perl). The latter of those rules is what perl uses and this is alluded to in perldata, unfortunately in passing rather than more explicitly; see the end of the section "List value constructors":
Note that just because a hash is initialized in that order doesn't mean that it comes out in that order.
So yes you shouldn't make any assumptions once it's gone in, but you are guaranteed (weakly, unfortunately) about the order pairs go in from a LIST.
Update: Not to mention this is the "recommended" way to do default values when you're using a hashref to do named arguments to a sub. See pp185-187 of Perl Best Practices.
We're looking for a Perl and Database Developer for Corporate Investments Group.
In reply to Re^4: Bulk hash population order
by Fletch
in thread Bulk hash population order
by JakeIII
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |