>I agree entirely.
>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.
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];
Currently, all three ]->[ sequences autoviv their LH operand, but really,
only the leftmost one, the assignment's target, ought to do that.
I seem to recall something about tying that one might snag in this
same coup--some trouble that Sarathy was having with mutlilevel
hash ties and how the deref wasn't tie-catchable. Well maybe that's
different. You can trap @{} or %{} now--on objects--but this won't
help you. Sigh. Sounds more like this is the "tied things can do
this, but op overloaded things can do this disjoint set of things"
problem.
--tom
