Outre le cas de gestion des erreurs en renvoyant un type somme, il me semble étrange qu'un langage moderne ne dispose pas de types sommes. Cela ne rend pas le système de type plus complexe, ni plus dur à implémenter.
Pour ce qui est des types somme en soi, ce n'est effectivement pas compliqué à implémenter : en fait, les interfaces de Go (qui sont des valeurs) peuvent être (et au besoin sont) utilisées exactement comme les types somme à l'aide d'un type switch (le cas courant de l'énumération se fait d'habitude avec des constantes). La seule différence, c'est que le nombre de types qui peuvent implémenter une interface n'est pas limité, contrairement aux types somme, ce qui veut dire qu'on ne peut pas faire de vérification d'exhaustivité. Une façon d'implémenter les type somme en Go sans introduire un concept trop différent, ce serait une façon de spécifier une liste fixe de types implémentant une interface explicitement (les interfaces sont implémentées implicitement autrement). Pour le moment, on dirait qu'ils n'ont pas considéré le bénéfice (check d'exhaustivité) suffisant pour introduire un nouveau concept, même s'il n'y a pas non plus d'opposition claire.
D'ailleurs, pour reprendre une partie de ton journal, c'était moins lourd de travailler avec des exceptions que des type option ou result.
Pour le coup, les exceptions peuvent conduire à du code concis, oui, sauf que c'est la méthode la moins explicite, invisible dans les signatures de fonction en OCaml, et offrant les bugs les plus inattendus.
Heureusement, depuis un an, on peut écrire un code moins abscons et plus proche de la version avec exception, mais c'est très récent.
J'ai pas vu passer ça ! J'imagine que c'est une extension ppx, ou alors directement intégré dans le langage ? Est-ce que ça couvre le cas des erreurs, idéalement avec une façon permettant de l'annoter ?
N'ayant jamais utiliser Rust, on doit s'y prendre comment pour travailler dans une telle monade
En Rust, ils se sont contentés de sucre syntaxique à l'aide d'une macro ? spécifique au cas du type option pour une erreur (type Result). C'est possiblement un bon compromis, surtout qu'ils ont fait l'effort de trouver une solution pour les annotations simples d'erreur (implémenter un trait de contexte pour Result).
[^] # Re: Raisons d'essayer Rust
Posté par anaseto . En réponse au journal Retour d'expérience sur les langages de programmation. Évalué à 2.
Pour ce qui est des types somme en soi, ce n'est effectivement pas compliqué à implémenter : en fait, les interfaces de Go (qui sont des valeurs) peuvent être (et au besoin sont) utilisées exactement comme les types somme à l'aide d'un type switch (le cas courant de l'énumération se fait d'habitude avec des constantes). La seule différence, c'est que le nombre de types qui peuvent implémenter une interface n'est pas limité, contrairement aux types somme, ce qui veut dire qu'on ne peut pas faire de vérification d'exhaustivité. Une façon d'implémenter les type somme en Go sans introduire un concept trop différent, ce serait une façon de spécifier une liste fixe de types implémentant une interface explicitement (les interfaces sont implémentées implicitement autrement). Pour le moment, on dirait qu'ils n'ont pas considéré le bénéfice (check d'exhaustivité) suffisant pour introduire un nouveau concept, même s'il n'y a pas non plus d'opposition claire.
Pour le coup, les exceptions peuvent conduire à du code concis, oui, sauf que c'est la méthode la moins explicite, invisible dans les signatures de fonction en OCaml, et offrant les bugs les plus inattendus.
J'ai pas vu passer ça ! J'imagine que c'est une extension ppx, ou alors directement intégré dans le langage ? Est-ce que ça couvre le cas des erreurs, idéalement avec une façon permettant de l'annoter ?
En Rust, ils se sont contentés de sucre syntaxique à l'aide d'une macro
?spécifique au cas du type option pour une erreur (type Result). C'est possiblement un bon compromis, surtout qu'ils ont fait l'effort de trouver une solution pour les annotations simples d'erreur (implémenter un trait de contexte pour Result).