Bah, je truve quand même bien pratique que l'erreur me soit retournée lors de la compilation de la fonction appelée. Si je compile une fonction pour qu'elle retourne un int et que je retourne un char dans le corps de la fonction, je préfère le savoir avant.
Chez nous une des règles pour Scala (qui a de l'inférence de type, mais qui ne fais pas non plus de miracles et arrive parfois à se perdre ou ne pas générer un "bon" type de retour) c'est "variable ou méthode publique" => "type explicite". Par contre pour les variables et méthodes internes / privées, au contraire on encourage à utiliser l'inférence, ça rend le code plus concis ; et de toute façon comme c'est forcément utilisé dans le même projet (ou alors c'est du code mort donc ça n'a pas lieu d'exister), le type inféré est donc forcément confronté à son appel et si bug il y a, il sera détecté à la compilation.
[^] # Re: Définition implicites ?
Posté par Sufflope (site web personnel) . En réponse au journal Non, l'inférence de types n'est pas du typage faible. Oui, elle rend les programmes plus lisibles. Évalué à 6.
Chez nous une des règles pour Scala (qui a de l'inférence de type, mais qui ne fais pas non plus de miracles et arrive parfois à se perdre ou ne pas générer un "bon" type de retour) c'est "variable ou méthode publique" => "type explicite". Par contre pour les variables et méthodes internes / privées, au contraire on encourage à utiliser l'inférence, ça rend le code plus concis ; et de toute façon comme c'est forcément utilisé dans le même projet (ou alors c'est du code mort donc ça n'a pas lieu d'exister), le type inféré est donc forcément confronté à son appel et si bug il y a, il sera détecté à la compilation.