Réponse.

Historique : Kotlin a été conçu dès le départ comme un langage avec une syntaxe concise mais strictement typée. Pour améliorer la lisibilité et réduire la duplication de code, une puissante inférence de type a été mise en œuvre.

Problème : Parfois, la déclaration de type devient superflue, compliquant le code. Cependant, la réduction excessive des types entraîne des difficultés lors de la lecture et la propagation des erreurs si le compilateur ne peut pas inférer le type.

Solution : L'inférence de type permet au compilateur de déterminer automatiquement la plupart des types sur la base de l'initialisation ou du contexte. Cependant, la typage stricte continue de contrôler la validité du code.

Exemple de code :

val name = "Kotlin" // String, le type est inféré automatiquement
var count = 5         // Int, le type est inféré automatiquement
val items = listOf(1, 2, 3) // List<Int>

// L'annotation de type explicite est requise si l'inférence n'est pas possible
val callback: (Int) -> Unit = { println(it) }

Caractéristiques clés :

Le type d'une variable ou d'une expression peut être inféré à partir de l'initialisation ou du contexte d'appel de la fonction
L'inférence de type n'est pas toujours possible : le compilateur exige une déclaration explicite si l'expression est ambiguë
L'inférence de type ne s'applique pas aux types de retour des fonctions et propriétés publiques : il est exigé de les spécifier explicitement pour la stabilité de l'ABI

Questions pièges.

Est-il possible de ne pas spécifier le type de retour d'une fonction publique ?

Non, si la fonction est publique, le compilateur exigera la déclaration explicite du type de retour pour la stabilité des interfaces et le support de l'interopérabilité Java.

Exemple :

// Erreur !
public fun compute(x: Int) = x * 2 // Nécessite explicitement : public fun compute(x: Int): Int = x * 2

Quel est le type de val x = null ?

Le compilateur ne pourra pas inférer le type, car null n'a pas de type sans contexte. Il est nécessaire de déclarer explicitement le type :

val x: String? = null

L'inférence de type peut-elle fonctionner pour des types génériques complexes lors de la traitement en chaîne de collections ?

Oui, mais si le type ne peut pas être inféré de manière univoque (par exemple, map transforme les types), il peut parfois être nécessaire de spécifier explicitement le type de la variable :

val values = listOf("1", "2").map { it.toInt() } // List<Int>, le type sera inféré

Erreurs typiques et anti-patterns

Manque de type explicite dans les fonctions API publiques
Surcharge du code avec des types implicites, rendant la lecture difficile
Erreur lors de la tentative d'inférer le type lors de l'initialisation via null

Exemple de la vie réelle

Cas négatif

Dans le projet, toutes les variables sont déclarées sans indiquer de type, ce qui complique la navigation et la compréhension du code pour d'autres développeurs ou nouveaux employés.

Avantages :

Moins de code
Écriture et refactorisation plus rapides

Inconvénients :

Difficile à lire et à maintenir
Facile de se tromper lors de la modification de l'initialisation

Cas positif

À l'intérieur des fonctions, les types des variables sont inférés automatiquement, mais dans toutes les API publiques, le type de retour et les types de paramètres sont toujours spécifiés explicitement.