Pourquoi l'inférence de type de Go échoue-t-elle dans les affectations de structure utilisant une déclaration abrégée ?

L'énigme de Go : manque d'inférence de type dans l'affectation de structure

Dans Go, l'attribution de valeurs à l'aide d'une syntaxe de déclaration abrégée est une pratique courante pour améliorer la lisibilité et l’efficacité du code. Cependant, cette simplicité peut dérouter les programmeurs lorsqu'ils sont confrontés à certains scénarios, comme le démontre l'extrait suivant :

i := 10
next := 11
prev, i := i, next

Cet extrait de code attribue la valeur de next à i tout en réaffectant simultanément i à prev. Ce comportement est intuitif et fonctionne comme prévu. Cependant, lorsqu'un champ de structure est impliqué, l'inférence de type échoue, comme le montre le code suivant :

type Foo struct {
    Bar int
}

f := Foo{10}
next := 11
prev, f.Bar := f.Bar, next

Dans ce cas, tenter d'attribuer une valeur à un champ de structure à l'aide de la syntaxe abrégée entraîne une erreur du compilateur : "non-name on left side of :="

Étonnamment, cette erreur ne se produit que lorsqu'il s'agit de structures. Pour résoudre l'énigme derrière ce comportement, nous examinons les mécanismes complexes d'inférence de type du compilateur Go.

Lorsque le compilateur rencontre une déclaration abrégée, il tente de déduire le type en fonction de l'expression de droite. côté de la mission. Pour les variables, ce processus est simple. Cependant, lorsqu'un champ struct est rencontré, le compilateur vérifie une correspondance entre le type du champ et le type de l'expression de droite.

Dans le premier exemple, le côté droit est un littéral entier (11) qui correspond au type de i. Par conséquent, le compilateur peut déduire que prev est également un entier et l'affectation réussit.

Dans le deuxième exemple, le côté droit est une expression impliquant un champ de structure (f.Bar). Puisque le compilateur doit s'assurer que le type du côté gauche (qui dans ce cas est f.Bar) correspond au type du côté droit, il se retrouve empêtré dans un conflit : le côté droit est un entier. , mais le côté gauche est un champ struct de type int. Cette divergence entraîne l'incapacité du compilateur à déduire le type de précédent, d'où l'erreur.

L'aspect déroutant de cette situation est que même si le message d'erreur indique "non-nom sur le côté gauche de :=" comme coupable, le problème sous-jacent semble résider dans l'échec de l'inférence de type en raison de l'implication d'un champ struct.

Ce comportement a été signalé comme un problème ouvert dans le problème Go tracker, soulignant les limites de l'inférence de type Go lorsqu'il s'agit de structures. Bien que cela ne soit pas techniquement considéré comme un bug, cela représente certainement un domaine dans lequel la rigidité du compilateur entrave les pratiques de codage intuitives.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!