develooper Front page | perl.perl5.porters | Postings from March 2013

Re: Perlfunc for each(), keys(), values() has been changed

Thread Previous | Thread Next
March 29, 2013 17:17
Re: Perlfunc for each(), keys(), values() has been changed
Message ID:
On 29 March 2013 18:10, Lukas Mai <> wrote:
> On 29.03.2013 18:06, Aristotle Pagaltzis wrote:
>> So how about this? Or something along these lines.
>>      Entries in a hash have a repeatable but arbitrary order. Therefore
>>      the order in which they are returned from C<keys>, C<values> and
>>      C<each> will match. Adding or deleting any keys changes this order
>>      arbitrarily and irreversibly, and you should expect the same set of
>>      keys in different hashes (or even in the same hash after adding and
>>      deleting keys) to yield a different order of entries. A special
>>      exception to this is made to allow you to safely delete keys from
>>      a hash while iterating over it: the entry most recently returned
>>      from C<each> or C<keys> can be deleted without changing the order of
>>      the other entries.
> This bit ("or C<keys>") makes no sense: 'keys' always returns a complete
> snapshot of the current keys. What does it mean for a key to be most
> recently returned from 'keys'?
> Besides, code like 'for (keys %foo)' isn't iterating over a hash; it's
> iterating over the list returned by 'keys', and in the loop body you can
> modify %foo however you want.

Actually id prefer to keep that language. Hypothetically it should be
possible to optimize

for my $key (keys %hash) {}

so that it does not copy the full key list, and id like to keep the
documentation at the level where it is clear what would have to remain
true if we did so.


perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About