scala: pourquoi l'initialisation underscore (_) fonctionne-t-elle pour les champs mais pas pour les variables de méthode?

Question

cela fonctionne:

scala> class foo[T] { 
    | var t: T = _ 
    | } 
defined class foo 

mais cela ne fait pas:

scala> def foo[T] = { 
    | var t: T = _ 
    | } 
<console>:5: error: local variables must be initialized 
     var t: T = _ 

pourquoi?

(on peut utiliser:

var t: T = null.asInstanceOf[T] 

)

Answer 1

Il y a a mailing list thread où Martin a répondu:

Il correspond à la machine virtuelle Java. Vous pouvez omettre une initialisation de champ mais pas une initialisation de variable locale. L'omission des initialisations de variables locales signifie que le compilateur doit être capable de synthétiser une valeur par défaut pour chaque type. Ce n'est pas si facile face aux paramètres de type, à la spécialisation, etc.

Lorsque vous appuyez sur la façon dont il est ou devrait être une distinction entre les champs et les locaux en matière de Scala synthétisant les valeurs par défaut, il a poursuivi en disant:

En termes de bytecode il y a une claire différence. La machine virtuelle Java initialise les champs d'objet par défaut et requiert que les variables locales soient initialisées explicitement. [...] Je ne suis pas sûr si nous devrions casser un principe utile de Java (les locales doivent être initialisées avant d'être utilisées), ou si nous devrions plutôt aller la pleine longueur et introduire la vérification d'initialisation basée sur le flux comme en Java. Ce serait la meilleure solution, l'OMI, mais cela exigerait un travail important en termes de spécifications et de mise en œuvre. Face à ces choix mon instinct naturel est de ne rien faire pour l'instant :-)

Donc, si je comprends bien, le compilateur Scala ne synthétise pas réellement les valeurs par défaut pour les champs d'objet, il produit bytecode qui laisse la machine virtuelle Java pour gérer ce.En accord avec SI-4437, Martin a approuvé le modèle null.asInstanceOf[T] dans la spécification de langage, apparemment pour ne pas être capable de supporter une meilleure alternative dans les contraintes existantes.

Answer 2

Ceci est défini à l'article 4.2 des Scala Language Specification (mes italiques)

Une définition de la variable var x: T = _ peut apparaître seulement en tant que membre d'un modèle. Il introduit un champ mutable avec le type T et une valeur initiale par défaut

Ceci, bien sûr, ne répond pas à la pourquoi cela devrait être ainsi!

Answer 3

Voici au moins un cas d'utilisation que je viens de découvrir. Lorsque la superclasse initialise les variables membres par réflexion, elle peut en fait initialiser les variables membres d'une sous-classe. Cependant, si une sous-classe initialise également la variable membre avec une valeur, cela aura pour effet d'écraser la valeur que la superclasse lui a donnée. Cela peut être évité en initialisant la variable membre des sous-classes avec le caractère de soulignement. C'est pourquoi la spécification de langage parle de donner à la variable une fonction getter qui renvoie la valeur actuelle un peu plus bas de la phrase citée dans la phrase de oxbow_lake.