Don't autovivify array and hash elements in sub parameters
authorGurusamy Sarathy <gsar@engin.umich.edu>
Thu, 6 Mar 1997 19:12:09 +0000 (14:12 -0500)
committerChip Salzenberg <chip@atlantic.net>
Thu, 6 Mar 1997 16:01:12 +0000 (04:01 +1200)
commit0ffc6623ceb5acc7b954e8cdbaeb8ba319474d7b
tree2be730645623743743ac02fddcf67ce716164ac9
parent651159bc74695f653cfb486793f878de6956d77c
Don't autovivify array and hash elements in sub parameters

On Thu, 06 Mar 1997 10:02:33 PST, Larry Wall wrote:
>: =head2 Why does passing a subroutine an undefined element in a hash create it?
>:
>: If you say something like:
>:
>:     somefunc($hash{"nonesuch key here"});
>:
>: Then that element "autovivifies"; that is, it springs into existence
>: whether you store something there or not.  That's because functions
>: get scalars passed in by reference.  If somefunc() modifies C<$_[0]>,
>: it has to be ready to write it back into the caller's version.
>
>I still think this behavior is bogus.  By default, it should simply be
>an error to pass an undefined value to a routine that wants to modify
>it.  (We can maybe modify that in the future with prototypes.)
>
>: =for p5p is this still true?
>
>Yes, unfortunately.  Is my editorial opinion leaking through here?  :-)

I hope you considered my one-line patch to revert this behavior to that of
perl5.001 (and perl4).  I still think we'd be doing a service to include
this patch in 5.004 (and remove that section from the FAQ and the docs).

One may still modify real scalars via $_[0] with the patch, so it has
little potential to cause breakage.

p5p-msgid: 199703061912.OAA20606@aatma.engin.umich.edu
op.c