Data::Printer always "autovivifiies" hash keys ? about data-printer HOT 3 CLOSED

bessarabov@5:~$ perl -E 'use DDP; %h = (); p $h{"one"}; p %h;'
undef
{
    one   undef
}
bessarabov@5:~$ perl -E 'use DDP { use_prototypes => 0 }; %h = (); p $h{"one"}; p %h;'
undef
undef
bessarabov@5:~$

< Zefram> couldn't do much else.  without the hash element being created, what would the reference returned by \ be referring to?
< TonyC> maybe a PVLV, but changing it might be a back-compat issue
< TonyC> garu: what you're seeing isn't autovivication - that refers to initializing an undef variable as a reference when you use it as one
< Zefram> fundamentally, \ is treating its operand as an lvalue, same as if it were on the lhs of an assignment
< Zefram> it's not well documented which operations will eagerly create the hash element like that.  foo($x{bla}) *also* treats $x{bla} as an lvalue, but doesn't eagerly create it.  it
                passes a PVLV to foo(), which can then create the hash element by assigning to $_[0]
< Zefram> this is a hedge because function arguments are usually taken by value but there's no type information to say which arguments specifically are taken by reference and so need the lvalue treatment
< garu> I see. Is there any consistency?
< garu> and, if not, should we consider forcing one? Even if, as TonyC mentioned, it might create back-compat issues?
< Zefram> it's consistent between perl versions, and is so long standing that it would be very troublesome to change
< Zefram> making all lvalue contexts behave the same would probably not be worthwhile