in reply to Re: New behavior of 'each' with respect to references
in thread New behavior of 'each' with respect to references

keys(@a) returns the keys of the array elements: 0..$#a
values(@a) returns the values of the array elements: @a

Same for unblessed array references.

Replies are listed 'Best First'.
Re^3: New behavior of 'each' with respect to references
by educated_foo (Vicar) on May 17, 2011 at 19:14 UTC
    Which just adds to the badness, since it's apparently not consistent with exists. This is 5.10: 
    % perl -le '@a=0..4; delete $a[1]; print exists($a[1])||0'
0

    [download]
    So the key "1" is present, but $a[1] doesn't exist...

    If just the auto-dereference of hashes had been added (and it had worked with tied scalars overloading %{}, and it didn't give some BS can't-turn-it-off error about "breaking encapsulation" like "smart" match does for blessed hashrefs (I don't have 5.14 ATM, so I'm not sure on this part)), it would probably be fine, but auto-dereference combined with broken acceptance of arrays just seems like a disaster.

[reply]
[d/l]
[select]

      So the key "1" is present, but $a[1] doesn't exist...

      Backwards. The element does exist even though exists says otherwise. (exists returns information about internal memory allocation.) This bug is why the use of exists is deprecated on array elements.

      it's apparently not consistent with exists.

      Being inconsistent with a buggy and deprecated feature is of no importance to me.

[reply]
[d/l]
[select]
        Being inconsistent with a buggy and deprecated feature is of no importance to me.
        I'm not sure how it's "buggy" -- it does exactly what it claims to do -- but it's clearly not "deprecated," since neither 5.8.9, 5.10.0, nor blead complains, even with -Mwarnings=deprecated. It's clearly a feature you don't like, but that's not the same as it being "deprecated."
[reply]
[d/l]

In Section Seekers of Perl Wisdom