Autovivification inattendue des arguments

Question

Apparemment, ma compréhension du pragma no autovivification est imparfaite, car le comportement non-mourir-en-ligne-19 du script suivant est extrêmement surprenant pour moi.

use 5.014; 
use strict; 
use warnings; 
no autovivification qw(fetch exists delete warn); 

{ 
    my $foo = undef; 
    my $thing = $foo->{bar}; 

    # this does not die, as expected 
    die if defined $foo; 
} 

{ 
    my $foo = undef; 
    do_nothing($foo->{bar}); 

    # I would expect this to die, but it doesn't 
    die unless defined $foo; 
} 

sub do_nothing { 
    return undef; 
} 

Exécution du script produit:

Reference was vivified at test.pl line 8. 

La question: pourquoi est $foo autovivified lorsque $foo->{bar} est fourni comme argument à un sous, même si no autovivification est en vigueur?

Answer 1

Dans un appel de sous-programme, les arguments d'une fonction sont aliasés en @_, il doit donc être possible de les modifier. Ceci fournit un contexte lvalue, ce qui va déclencher l'autovivification.

Quand nous regardons à travers la description des fonctionnalités que vous utilisez dans autovivification, ils couvrent:

• 'fetch' - "rvalue expressions déréférencement"
• 'exists' - « expressions déréférencement qui sont parties d'un existe "
• 'delete' -" expressions de déréférencement qui font partie d'un supprimer "

Aucun de ces composants ne traite des valeurs lues (ni warn).

Pour arrêter autovivification dans sous-programme appelle aussi bien que vous devez ajouter store

Transforme hors autovivification pour les expressions déréférencement de lvalue, tels que:   [...]

où docs procéder à exemples, y compris les appels de sous-programmes.

Quand je l'ajoute à votre code,

no autovivification qw(fetch exists delete warn store); 
# ... 

Je reçois

 
Reference was vivified at noautoviv.pl line 8. 
Reference was vivified at noautoviv.pl line 16. 
Died at noautoviv.pl line 19.