I'm pretty sure the answer is the same as in your previous thread that you referenced: map is providing lvalue context to its args, while the other two examples of string concatenation do not, hence the hash value is autovivified. (Update: I added LanX's suggested workaround to the following example).
$ perl -wMstrict -MData::Dump -e 'my %h; map{$_} $h{X},"$h{Y}"; dd\%h' Use of uninitialized value $h{"Y"} in string at -e line 1. { X => undef }
See also your previous thread No autovivification, for loop aliasing, lvalue vs rvalue in for loops.
I'm curious why you have so many issues with autovivification? Personally, I hardly ever do, because I use exists, or keys when looping over multiple hash keys. And if I have a situation where I want to control which keys can be accessed, I use locked hashes from Hash::Util.
In reply to Re: Sometimes undef is initialized and sometimes not when hash values are fed to grep
by haukex
in thread Sometimes undef is initialized and sometimes not when hash values are fed to grep
by leszekdubiel
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |