Fallo en el cambio de tipo: una explicación detallada

El cambio de tipo en Go permite un manejo eficiente de los valores en función de sus tipos concretos. Sin embargo, a diferencia de las declaraciones de cambio de caso estándar, la falla no se permite explícitamente en el cambio de tipo. Esta elección de diseño plantea dudas sobre su justificación.

Comprender las razones

La especificación Go establece que el "fallthrough" no está permitido en los interruptores de tipo. Esta prohibición se debe a varios factores:

• No coincide el tipo: En un cambio de tipo, la variable que se evalúa cambia de tipo dependiendo de la rama de caso ingresada. Por ejemplo, si a la variable se le asigna un booleano en una rama y una cadena en otra, la falla daría como resultado una falta de coincidencia de tipos.
• Comportamiento confuso: Permitir la falla en los cambios de tipo introduciría errores ambiguos semántica. Considere un cambio donde a una variable se le asigna un valor booleano en una rama anterior. Si se permite la falla, no está claro cómo se debe tratar la variable en ramas posteriores. ¿Debería seguir siendo booleano o convertirse en una interfaz{} que contenga un booleano o un valor del nuevo tipo?

Un ejemplo para aclarar

Para ilustrar el problema, considere el siguiente código:

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 se permitiera la transferencia alternativa, no está claro qué tipo se imprimiría para el caso de cadena. Sería ambiguo si debo seguir siendo booleano o convertirme en una interfaz{} que contenga tanto un booleano como una cadena.

Soluciones alternativas

Aunque no se permite la solución alternativa modificadores de tipo, existen formas alternativas de lograr un comportamiento similar:

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
}

Este enfoque permite un manejo más específico de diferentes tipos sin introducir discrepancias de tipos o ambigüedad.