This has been discussed on p5p many many times. And many times
I have agreed with what you wrote. However one thing you did not mention,
but does need to be considered is
func($x{1}{2}{3})
at this point you do not know if this is a read or write access as
the sub could do $_[0] = 'fred'. If this can be handled in someway
so that the autoviv does not happen until the assignment then OK,
but otherwise I think we would have to stick with perl5 semantics
Also we would probably need a use autoviv pragma so that perl5
scripts which are ported, and rely on the autivivify of hashes,
will still work as before.
Graham.
On Fri, Dec 22, 2000 at 03:26:03PM -0500, Deven T. Corzine wrote:
> Can the autovivication behavior be changed slightly for Perl 6?
>
> Specificly, can we suppress autovivication in read-only circumstances, and
> evaluate the expression as "undef" immediately instead of autovivicating
> empty data structures that didn't exist before?
>
> The current behavior in Perl 5 is inconsistent. Attempting to reference a
> hash or array element doesn't normally cause that element to spring into
> existence, but attempting to reference substructures DOES suddenly cause
> that substructure to spring into existence. This behavior is desirable
> when writing to that substructure, but undesirable when reading from it,
> and inconsistent with the normal behavior of single-level perl structures.
>
> Referencing a nonexistent entry in a hash or array doesn't create that
> entry UNLESS it's autovivified as a reference. "%x = (); $x{1};" does NOT
> have the same effect as "%x = (1 => undef);"; why does "%x = (); $x{1}{1};"
> have the same effect as "%x = (1 => {});"? If the programmer has never
> stored any values into %x, it would be reasonable to expect it to remain
> empty; why violate this reasonable expectation just because of an attempted
> reference to a nonexistent structure?
