Pourquoi ne puis-je pas utiliser de méthodes partagées avec les contraintes d'union de Go Generics ?

Contraintes d'union dans les génériques Go : limitations non résolues

Dans le domaine des génériques Go, les contraintes d'union de type ont suscité une certaine confusion. Lorsque vous tentez d'utiliser une méthode courante pour les types au sein d'une contrainte d'union, le compilateur génère une erreur, laissant les développeurs perplexes.

Considérez le code suivant :

type A struct {}
type B struct {}
type AB interface { *A | *B }

func (a *A) some() bool { return true }
func (b *B) some() bool { return false }
func some[T AB](x T) bool { return x.some() } // Compilation error

Le compilateur se plaint que x.some n'est pas défini, même si *A et *B implémentent la méthode some. Cela soulève la question : pourquoi définir une contrainte d'union si les méthodes partagées ne peuvent pas être utilisées ?

La solution de contournement, suggérée par le tracker Go, consiste à ajouter la méthode à la contrainte d'interface :

type AB interface { *A | *B ; some() bool }
func some[T AB](x T) bool { return x.some() } // Compiles

Cependant, il s’agit d’une solution imparfaite. Les contraintes d'union de types de Go devraient permettre le partage de méthodes sans nécessiter une déclaration d'interface explicite. Malheureusement, il s'agit d'une limitation de Go 1.18, documentée dans les notes de version :

Le compilateur Go ne prend actuellement en charge que l'appel d'une méthode m sur une valeur x de type paramètre de type P si m est explicitement déclaré par l'interface de contrainte de P. .

Cette limitation devrait être résolue dans Go 1.19. D'ici là, les développeurs doivent s'appuyer sur la solution de contournement ou définir des interfaces unifiées pour les méthodes partagées.

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!