It's not undocumented behavior. It's just behavior that's documented in a different place, unrelated to hashslices. Basically, undef is a keyword that takes an array. @hsh{@ary} evaluates to an array. But, to do that, Perl needs to autovivify all the slots in the hash in order to return the values. Heck, anything that takes a list will do.

undef @hsh{@ary};
chomp @hsh{@ary};
chop @hsh{@ary};
map $_, @hsh{@ary};
1 foreach @hsh{@ary};
[download]

Those will all do the trick. The undef is a no-op to provide something that requires evaluation of a list.

Basically, undef is a keyword that takes an array.

Yes, but a slice is not an array, and undef is explicitly not a listop.

undef

Undefines the value of EXPR, which must be an lvalue. Use only
on a scalar value, an array (using @ ), a hash (using % ), a
subroutine (using & ), or a typeglob (using * ).
...
Note that this is a unary operator, not a list operator.
[download]

What happens when you undef a slice is that it is converted into a list, which is then evaluated in scalar context, which yields the last element of the slice as the scalar value. That value (and only that value) is then set to undef (so it's not a no-op; if you want a no-op use the \ operator, which will take a list). Contrast that with handing it an array proper. The entire array is then undefined.

The conversion from hash slice to list to scalar is not documented, and should generate a warning. In fact, if you try to pass undef a list of array elements, you will get an error.

there is no such thing as a list in scalar context

---

Caution: Contents may have been coded under pressure.

I thought that seeing it on my screen would make it easier to understand. I'm missing something here. I was kind of expecting the array to be unchanged ... but that's not what happened:

$ perl -MData::Dumper -e '@x=0..10; undef @x[2..7]; print Dumper(\@x)'
$VAR1 = [
          0,
          1,
          2,
          3,
          4,
          5,
          6,
          undef,
          8,
          9,
          10
        ];
[download]

Obviously, if undef worked as is otherwise expected, all numbers from 2 through 7 would be undef. What surprised me here is that 7 still is undef'd. Something funky is happening.

Not that I'd ever have this problem in production code - I don't ever have the need for this type of behaviour (undefing a slice)... and would have thought about using @x[2..7] = () first anyway.

Update: Yeah, Roy Johnson explained it - I see that now. However, it's still a bit buried, and Roy Johnson's lengthier explanation below is much clearer. Thanks, Roy!