in reply to Keys() required to autovivify?

Because autovivifying will assign a "default value" of undef when you do not supply an assignment (rhs) value as part of the autovivifying expression.

In your first example, the enclosure within  %{...} requires that the enclosed expression must yield a reference to a hash (not doing so is an error), and of course, undef cannot be interpreted as a hash ref.

In your second example, the "keys()" function is only looking at keys in the hash, not at values, so it doesn't matter that the "default value" being assigned to $h{x} happens to be undef.

UPDATE: When I first wrote and posted the above, it seems I was missing an important point, and I think GrandFather came closer to getting it right in his reply below: there is something "DWIM-ishly" odd going on with the keys() function, and I personally cannot explain why the second snippet in the OP does not trigger an error. On reflection, it strikes me as strange, and I understand jrw's continuing sense of confusion. (But ikegami and shmem have helped a lot with their replies, and I am less confused now.)

Replies are listed 'Best First'.
Re^2: Keys() required to autovivify?
by jrw (Monk) on Dec 30, 2007 at 07:56 UTC
    I don't understand what you're saying. In the second example, %{$h{x}} is being autovivified by the use of keys() to create an empty hash at $h{x}. In the first example, the exact same expression, but without the call to keys(), is a syntax error.
[reply]

      Using $h{x} is sufficient to autovifiy a key/value pair if there is no key/value pair for the key 'x' in the hash %h.

      In the first case you give, the key 'x' is added to the hash (the $h{x} bit does that) with the value undef. The %{...} then tries to dereference the undef and generates the error that you see.

      The second case is equivalent to:

      my $ref = undef;
keys %{$ref}; # or: keys %$ref;

      [download]

      which, somewhat surprisingly, is fine and is about the same as asking for the keys of an empty hash. I guess this is an element of DWIM coming into play - if you ask for the keys of a hash reference that you haven't gotten around to assigning any key/value pairs to yet, then a list of not keys (and no errors generated) is a pretty reasonable thing to do.

      Perl is environmentally friendly - it saves trees
[reply]
[d/l]
[select]
        But using $h{x} will not add an undef value into $h{x}. It just returns an undef value since $h{x} doesn't exist. I still don't see what magic keys() is using to get around the syntax error message.
[reply]

In Section Seekers of Perl Wisdom