Retour dans le changement de type : une explication détaillée

Le changement de type dans Go permet une gestion efficace des valeurs en fonction de leurs types concrets. Cependant, contrairement aux instructions switch-case standard, le repli est explicitement interdit dans le type switch. Ce choix de conception soulève des questions sur sa justification.

Comprendre les raisons

La spécification Go indique que le « fallthrough » n'est pas autorisé dans les commutateurs de type. Cette interdiction provient de plusieurs facteurs :

• Incompatibilité de type : Dans un changement de type, la variable évaluée change de type en fonction de la branche de cas saisie. Par exemple, si la variable se voit attribuer un booléen dans une branche et une chaîne dans une autre, le fallthrough entraînerait une incompatibilité de type.
• Comportement déroutant : Autoriser le fallthrough dans les commutateurs de type introduirait une ambiguïté sémantique. Considérons un commutateur où une variable se voit attribuer un booléen dans une branche précédente. Si le repli est autorisé, la manière dont la variable doit être traitée dans les branches suivantes n'est pas claire. Doit-il rester un booléen ou devenir une interface{} contenant soit un booléen, soit une valeur du nouveau type ?

Un exemple de clarification

Pour illustrer le problème, considérez le code suivant :

switch i := x.(type) {
case int:
    fmt.Printf("%T\n", i) // prints "int"
case bool:
    fmt.Printf("%T\n", i) // prints "bool"
    fallthrough
case string:
    fmt.Printf("%T\n", i)
}

Si le remplacement était autorisé, il n'est pas clair quel type serait imprimé pour la casse de la chaîne. Il serait ambigu de savoir si je dois rester un booléen ou devenir une interface {} contenant à la fois un booléen et une chaîne.

Solutions alternatives

Bien que le repli ne soit pas autorisé dans tapez des commutateurs, il existe d'autres moyens d'obtenir un comportement similaire :

switch i := x.(type) {
case bool, string:
    if b, ok := i.(bool); ok {
        // b is a bool
    }
    // i is an interface{} that contains either a bool or a string
}

Cette approche permet une gestion plus spécifique de différents types sans introduire d'incompatibilités de types ni d'ambiguïté.