Re^3: Undesirable parent hash keys (concept?)

[CountZero]

Then the only practical solution is to switch off autovivification. But take care to do it only in a limited scope because many other modules may still need it and could break unexpectedly if it is switched off.;

It is probably more safe to do a no autovivification 'exists'; as this turns off autovivification for dereferencing expressions that are parts of an exists only, such as :

exists $arrayref->[1][2][$idx]
exists $hashref->{this}{that}{$key};

and then make sure you change your tests to include the exists function.

[tobyink]

autovivification has lexical scope, so if other modules rely on autovivification, then using no autovivification in your script/module shouldn't harm them. (The only exception I could think of would be modules that play with B::Hooks::Parser, etc, to do weird stuff within your lexical scope.)

I don't see much value in explicitly specifying the 'exists' option for the autovivification pragma, as the default options are pretty sane: when no autovivification is in effect, autovivification will still be allowed for "store" operations...

use strict;
use warnings;
no autovivification;  # default options

use Data::Dumper;

my $ref = undef;
$ref->{foo}[0]{bar}[0] = 42;  # store
print Dumper $ref;