Réponse

Le langage Go utilise une typage statique stricte. Cela signifie que le type de chaque variable est connu au moment de la compilation, et le compilateur n'autorise pas les opérations avec des types incompatibles.

Il existe deux types de conversion de types :

1. Conversion explicite de types (Type Casting) – lorsque le programmeur précise explicitement le type souhaité.
2. Assertion (type assertion) – appliquée aux interfaces pour vérifier un type sous-jacent spécifique.

Exemple de conversion explicite :

var i int = 42
var f float64 = float64(i)

Exemple de type assertion :

var i interface{} = "hello"
s, ok := i.(string)
if ok {
	fmt.Println("Valeur String :", s)
} else {
	fmt.Println("i n'est pas une chaîne")
}

La conversion n'est possible que entre des types de base compatibles (int → float64, rune → int32, mais string → int — impossible).

Question piège

L'interface{} peut-elle stocker une valeur nil, et comment vérifier correctement que la variable de type interface est réellement nil ?

Le piège courant est de comparer l'interface contenant une valeur nil directement avec nil :

var err error = nil
var i interface{} = err
fmt.Println(i == nil) // Attend true, mais sera false !

La bonne façon :

Vérifiez que l'interface elle-même est nil et que la valeur imbriquée est nil :

if i == nil || reflect.ValueOf(i).IsNil() {
	fmt.Println("i est réellement nil")
}

Exemples d'erreurs réelles dues à une méconnaissance des subtilités du sujet

---

Histoire

Dans un projet backend, un développeur tentait de gérer différentes erreurs à travers interface{}, les comparant à nil. En conséquence, l'erreur ne pouvait pas être correctement détectée — des bogues cachés et une logique incorrecte de retour d'erreurs au client sont apparus.

---

Histoire

La migration entre float64 et int sans conversion explicite a causé une perte de données silencieuse : les valeurs étaient arrondies ou transférées de manière incorrecte, car le compilateur Go exige une conversion explicite pour de telles opérations.

---

Histoire

Lors de la désérialisation des valeurs d'interface en travaillant avec map[string]interface{} (par exemple, à partir de JSON), des types inattendus de nombres (float64) ont conduit à des pannes lors de l'utilisation d'assertion de type sans vérification supplémentaire de ok — le service était en panne en raison d'une erreur d'exécution.