> >In fact, I shall extend RFC 128 to allow subroutine parameter to specify
> >that they are non-autovivifying.
>
> I'm not sure why it matters to the subroutine. We've already got
> the hack so that
>
> fn( $a[$i] )
> or
> fn( $h{$k} )
>
> will only autoviv those puppies if you muddle up $_[0]. This seems
> sufficient.
But this:
fn( $h{key}{subkey} )
always autovivifies $h{key}, whether or no you muddle that puppy.
Hence the need to be able to specify that C<fn>'s single argument be
evaluated in a non-autovivifying (an auto-mortifying???) context.
> As for the rest, the behaviour has to be addressed where it's happening:
> with the internals dereferencing operator itself. How would you attach
> a "nonautoviv" attribute to some pieces here:
>
> $z[$i][$j] = $x[$i][$j] + $y[$i][$j];
CORE::OP_ADD ( $leftop : nonav, $rightop : nonav ) { ... }
CORE::OP_ASSIGN ( $lval, $rightop : nonav ) { ... }
Damian
