Front page | perl.perl5.porters |
Postings from July 2013
On 10 July 2013 03:56, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote: > > The docs on `each` were revisited during the hash overhaul in 5.17. The > assertion is that you can delete the most recently retrieved key safely, but > deleting any other key may change the iteration order. I believe this was also > asserted on the list. > > The docs for FieldHash say: > >> If anything you do inside the loop could cause an object to go out of scope, >> a random key may be deleted from the hash you are looping over. > > This matches the assertion in the `each` docs. > > Unless perlfunc's entry for each is wrong, there is no contradiction. > > I believe Yves said that he did work to keep deleting the current key safe. > MJD's mistake, if any, would be to say that you could delete *any* key you'd > already visited, rather than the *one* key you *just* got. > > I think the docs are correct. Perhaps someone -- Yves? -- could confirm. My understanding of the rules regarding native perl hashes is that we make the weakest guarantee possible: that deleting the most recent key returned by each is "safe", which means that we will visit the remaining keys and we will not visit any keys we have already seen. We do not even commit to visiting the remaining keys in the same order we would have if we had not deleted an item. Which means that deleting an arbitrary key is allowed to change the order. The current implementation as far as I know actually results in *all* deletes being safe, but we make no such guarantee. But I believe that the documentation in question is about field hashes, and not normal perl hashes, so it seems to me the question is irrelevant to answering this ticket. They seem like some kind of tie, and are definitely magic, so it seems to me they can do whatever they like. cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Previous | Thread Next