On Wed, Jan 30, 2019 at 5:50 PM James E Keenan via RT < perlbug-followup@perl.org> wrote: > This behavior is what the Perl documentation calls "autovivification". > See 'perldoc perlreftut' -- particularly the section titled "Solution" (as > distinct from the section titled "The Solution"). > > To paraphrase that section of perlreftut ... > > This is Perl, so it does the exact right thing. It sees that you are > asking whether there is a hash element (a) keyed on 'population', (b) which > has a defined value, and (c) which is an element of an anonymous hash which > (d) itself is not yet created but which (e) is to be the value of an > element keyed on 'London' within %cities. So Perl helpfully makes a new, > empty, anonymous hash for you, installs it as the value of the 'London' > element within %cities. This is called autovivification -- bringing things > to life automatically. Perl saw that the element keyed on 'London' wasn't > in %cities, so it created a new hash entry automatically. > [Jim, this isn't directed at you personally -- it's an old email and I know that you were just quoting "perlreftut".] For the record, I strongly disagree with the statement quoted above: "This is Perl, so it does the exact right thing." Perl's behavior is justifiable and easier to implement, but it is absolutely NOT "the exact right thing" from the programmer's perspective. The "exact right thing" would DWIM and only autovivify structures when necessary to store a new value, and NEVER autovivify missing intermediate data structures on a read-only access. This is what the programmer wants and intuitively expects. Perl tries to DWIM as much as possible, and autovivification of intermediate data structures used in a read-only fashion is an example where Perl falls short of this ideal. It's not a big deal, but pretending like this behavior is *preferable* by calling it "the exact right thing" is simply whitewashing. DevenThread Previous | Thread Next