Les types sommes pourraient être ajoutés, on est d'accord. Mais ce pour quoi ils sont utiles est déjà couvert (en moins bien si on veut) par les constantes (enums) et les interfaces (avec assertion de type) pour le reste. Ajouter maintenant les types somme signifierait que les programmeurs auraient maintenant deux façons différentes d'écrire certains programmes. Pour les fonctions renvoyant une erreur on aurait maintenant deux signatures : celles qui font comme maintenant, et celles qui renvoient un type option. Je comprends qu'étant donné l'actuel ça ne soit pas très cohérent de les ajouter. Tu vas me dire que c'est de la complexité accidentelle que d'utiliser constantes et interfaces pour faire des sommes (disjointes si on veut, il suffit d'implémenter une interface spécifique), mais personellement je me risquerais à parier que, dans ce cas, la complexité accidentelle est moindre que celle d'étendre le langage.
Le concept de l'interface typée vérifiée par des couples (type, valeur) (en interne) est peut-être pas satisfaisant en théorie des types, mais c'est quand même très flexible pour vraiment pas cher (réflection quasi-gratuite en prime), je trouve, et une avancée par rapport à un langage purement dynamique.
[^] # Re: go 2.0
Posté par anaseto . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 2.
Les types sommes pourraient être ajoutés, on est d'accord. Mais ce pour quoi ils sont utiles est déjà couvert (en moins bien si on veut) par les constantes (enums) et les interfaces (avec assertion de type) pour le reste. Ajouter maintenant les types somme signifierait que les programmeurs auraient maintenant deux façons différentes d'écrire certains programmes. Pour les fonctions renvoyant une erreur on aurait maintenant deux signatures : celles qui font comme maintenant, et celles qui renvoient un type option. Je comprends qu'étant donné l'actuel ça ne soit pas très cohérent de les ajouter. Tu vas me dire que c'est de la complexité accidentelle que d'utiliser constantes et interfaces pour faire des sommes (disjointes si on veut, il suffit d'implémenter une interface spécifique), mais personellement je me risquerais à parier que, dans ce cas, la complexité accidentelle est moindre que celle d'étendre le langage.
Le concept de l'interface typée vérifiée par des couples
(type, valeur)(en interne) est peut-être pas satisfaisant en théorie des types, mais c'est quand même très flexible pour vraiment pas cher (réflection quasi-gratuite en prime), je trouve, et une avancée par rapport à un langage purement dynamique.