Das ist eine Feinheit, die ich mit keys() gefunden habe.
Ich bin höchst verwundert darüber, warum das erste Snippet keinen Dereferenzierungsfehler ergeben würde. Wenn ich Data::Dumper verwende, wird klar, dass im ersten Ausschnitt $d->{cd} autoviviert wird, um {} zu sein.
Warum muss keys autovivifizieren? Ich habe versucht, die perldoc dafür zu lesen, konnte keine befriedigende Antwort finden. keys legt keinen Alias fest ( $_ , etc), also muss Perl nicht denken, dass $d->{cd} im Lvalue-Kontext sein muss, oder? (Ich verstehe, wenn der Ausdruck in lvalue Kontext Autovivification sein muss passiert wie hier .
Ein relevanter Beitrag .
Beachten Sie, dass Schlüssel in der Tat ein lvalue sein können (indem Sie die erwartete Anzahl von Elementen für den Hash festlegen).
Aber selbst wenn Schlüssel selbst nicht in einem Lvalue-Kontext verwendet werden, hat dies den Nebeneffekt, dass der Iterator eines Hashes zurückgesetzt wird.
Es ändert also den Hash und gibt der Dereferenz einen Lvalue-Kontext, der sie autovivifizieren lässt.
Nach einigen Nachforschungen und Nachfragen habe ich festgestellt, dass dies mit der Tatsache zu tun hat, dass $d->{cd} an eine Subroutine übergeben wurde, nicht die Tatsache, dass es keys war. Zum Beispiel,
Dies wird auch autovivify; Dies liegt daran, dass intern perl in der Lage sein muss, einen Alias für Funktionsargumente zu setzen.
Innerhalb von foo() haben wir einen Alias-Satz $_[0] = $d->{cd} Aber das bedeutet $d->{cd} muss lvalwertfähig sein, da Unterprogramme in Perl davon ausgehen, dass Sie etwas wie $_[0] = "123"; tun können, damit die Autovivifikation erfolgen muss.
Tags und Links perl hash key dereference autovivification