Don't ask to ask, just ask | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
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. In reply to Re: Autovivification of scalars in sub calls
by Tanktalus
|
|