To be honest, the only places I rely on autovivication are: hash values, array values, and anywhere explicitly documented to use autovivication (e.g., IPC::Open3), although in that last case, I got bit where it promised autovivication and didn't deliver, so I manually "vivified" the handles before passing them in.
Top-level references, for some reason, I just never tried to use autovivication. I'm not sure why.
Anyway, we already know that builtins are treated special in many ways - this just seems to be another one. I'm sure we could do something similar with XS somehow .. but I'm not an XS expert. I think perl6 solves this difference making builtins behave the same way as user-defined functions, or, more to the point, allowing user-defined functions to gain builtin-like semantics.
In your case, the user-defined function autovivifies the array to figure out what @_ will contain. Why perl doesn't need to do likewise for builtins, I'm not sure. Or why perl doesn't figure out that $x being undef will autovivify to an empty list and just skip the autovivication, I'm not sure.
Note that builtins that treat the array as an lvalue (like using '@' in a prototype) do autovivify:
so it's not all builtins. But it does seem to be all user-defined functions - or at least I've not found a counter example.$ perl -Mstrict -le 'my $x; push(@$x,"z"); print "=> ", ref $x, $/' => ARRAY
In reply to Re: Autovivification of scalars in sub calls
by Tanktalus
in thread Autovivification of scalars in sub calls
by tlm
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |