Exists and autovivification (was: Looping through a hash reference...)

It shouldn't be particular to exists(), it should be a general rule: autovivification should only happen to lvalues. When non-lvalues are evaluated, they short-circuit as soon as they encounter an undefined component, and return undef. exists() naturally returns false when checking a component of an undef (e.g., your latter example evaluates as exists(undef, 'c')).

Of course, there's probably some code by now that relies on autovivification of non-lvalues, and that argues strongly against implementing this suggestion. I can't think of any other arguments against it, though doubtless someone else can.

We're not really tightening our belts, it just feels that way because we're getting fatter.

Comment on Exists and autovivification (was: Looping through a hash reference...) Download Code

Replies are listed 'Best First'.
Re: Exists and autovivification (was: Looping through a hash reference...) by ihb (Deacon) on Jun 13, 2004 at 17:18 UTC
Code such as `$bazref = \$foo{bar}{baz}` [download] too relies on autovivification.	[reply] [d/l]
Re^2: Exists and autovivification (was: Looping through a hash reference...) by Roy Johnson (Monsignor) on Jun 13, 2004 at 20:38 UTC
Good point. Taking a reference of anything would have to autovivify it. We're not really tightening our belts, it just feels that way because we're getting fatter.	[reply]
Re^2: Exists and autovivification (\lvalue) by tye (Sage) on Jun 24, 2004 at 19:44 UTC
Taking a reference is an "lvalue context". So this isn't an exception but part of the same rule. Even in C, you can't take the address of a non-lvalue (it might be 'const' aka 'read-only', of course). The `$hash{key1}{key2}` autovification of 'key1' has long been considered a minor bug. So I'd hope that backward compatability to bugs isn't a good reason to a prevent fixing them. - tye	[reply] [d/l]