autovivified hash key with foreach $x ( @{$h{a}} ) {}

[Danny]

This

perl -we 'my %h; my @x = ( @{$h{a}} )'

gives 'Use of uninitialized value $h{"a"} in array dereference at -e line 1.'

which seems desirable, but

perl -wE 'my %h; foreach $x ( @{$h{a}} ) { say $x }; exists $h{a} and 
+print "true\n"'

creates the $h{a} key which seems kinda bad. Why is the foreach context treating ( @{$h{a}} ) differently?

[Anonymous Monk]

Because the second is lvalue context, where autoviv happens.

[Danny]

I see. Thanks.

[LanX]

Probably because of the aliasing of $x

Edit

Here another kind of aliasing with the same "weirdness"

$ perl -wE 'my %h; sub tst{ say @_ }; tst ( @{$h{a}} ); exists $h{a} a
+nd print "true\n"'

true

I seem to remember we already had a similar discussion here not long ago...

Update

Now I remember, because of the aliasing, it's also an lvalue, i.e. it's potentially possible to assign to $x and consequently create the key.

But the autovivification happens at the moment of aliasing, and not at the moment of assignment, because it's too complicated to implement.

And yes, we had this discussion some month ago, I'll try to find the thread.

Bottomline was that it's very complicated to cover all edge cases, and the devs want to keep the code simple.

Update

Compare unexpected modify hash in a distance with grep { $_ }

[ikegami]

because of the aliasing, it's also an lvalue

More precisely, because a modifiable alias is required.

because it's too complicated to implement.

I don't think so. We already do that for hash elements, and the same approach could be used to handle more complicated cases. It's a question of performance.

[LanX]

Did you read the older thread I linked to?