lvalue vs rvalue. When an undefined value is dereferenced to be used as an lvalue, it gets autovivified.

>perl -Mstrict -wle"my $r; my @x; @x=@$r; print $r"
Can't use an undefined value as an ARRAY reference at -e line 1.

>perl -Mstrict -wle"my $r; my @x; @$r=@x; print $r"
ARRAY(0x225280)
[download]

map appears to expect an lvalue, possibly because it aliases.

>perl -Mstrict -wle"my $r; my @x = map{ $_ } @{ $r }; print $r"
ARRAY(0x225258)
[download]

More examples where aliasing is involved:

>perl -Mstrict -wle"my $r; my @x; for(@$r){} print $r"
ARRAY(0x225280)

>perl -Mstrict -wle"my $r; my @x; sub{}->(@$r); print $r"
ARRAY(0x225280)
[download]

Update: Oops, fixed mention of rvalue where I meant lvalue. Re-ordered post for better readability. Added extra examples.

Interesting! It has some useful properties as is, but caught me out refactoring a bit of code.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Not directly related to your observation, but maybe still interesting in the wider context of autovivifying things...  While trying to get some third-party code to run under strict, I recently stumbled across the phenomenon that something like

if (%$href) { print "has elements" }
[download]

produces "Can't use an undefined value as a HASH reference" when $href is undefined (under strict, that is, works fine without strict), while

my @keys = keys %$href;
my @vals = values %$href;
while (my ($key, $val) = each %$href) { ... }
[download]

all work fine under strict, because they autovivify the hash.

The explanation based on aliases being created (implying lvalue-ness) only holds partially here: evaluating the hash in scalar context presumably does not create aliases (so the behaviour is "as expected"); values does create aliases (so that's as expected, too); but keys does not create aliases, at least not in a way that you could say

for (keys %$href) {
    $_ = "foo";
}
[download]

and have the keys in the hash be modified.  Still, it obviously autovivifies.

C:\test>perl -Mstrict -wle" my $r = undef; my @x = map{ $_ } @{ $r }"
[download]

 DB<25> use strict; my @a = 0..5; my @b = map { $_ = $_*$_ } @a; print
+ "@a\n@b"
0 1 4 9 16 25
0 1 4 9 16 25
[download]

Many Thanks

Casiano

Is it because map code can change the list argument...

That is the implication of ikegami's post.

For a definitive answer we'd need someone from p5p to comfirm that.

Update: That said, if it was being autovivified in the normal sense, you'd expect that either it would persist, or at least values derived from it to persist, but neither is the case:

C:\test>perl -Mstrict -wle
"my $r= undef; my @x= map ++$_,@{$r};print qq[[@$r]\n[@x]]"
[]
[]
[download]

I think there is a bug there somewhere, but it might be hard to define.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

It does persist—you've autovivified $r as a reference to an array, but that array is still empty:

% perl -Mstrict -wle 'my $r = undef; map ++$_, @$r; print $r;'
ARRAY(0x10116180)
[download]