nil n'est pas du tout équivalent à unwrap en Rust. Dans un cas, on peut avoir un panic sans le savoir (on croit avoir un objet valide, mais pas de chance, c'est un nil), dans l'autre cas, on a un type Result qu'on peut choisir d'ignorer explicitement (ce qu'on ne fait pas dans un code en production, normalement).
De plus, ce n'est pas parce qu'on peut passer nil comme paramètre de méthode qu'il est typé. Un nil dans ce genre de langage n'est pas typé, puisque rien de distingue un nil d'un autre, si je puis m'exprimer ainsi. En revance, en Rust, pour garder cet exemple, un None a un type qui est Option<T>, donc un Foo "nul" et un Bar "nul" n'ont pas le même type: Option<Foo>::None vs Option<Bar>::None. Le fait d'avoir des références nulles fait qu'il y a un typage faible localement.
Pour avoir utilisé les 2 types de gestion d'erreur, je fais tout pour éviter les langages avec référence nulle qui obligent à vérifier tout le temps qu'on a bien un objet valide.
[^] # Re: "Billion dollar mistake"
Posté par Boiethios . En réponse au lien Odin: Go done right?. Évalué à 3.
niln'est pas du tout équivalent àunwrapen Rust. Dans un cas, on peut avoir un panic sans le savoir (on croit avoir un objet valide, mais pas de chance, c'est unnil), dans l'autre cas, on a un typeResultqu'on peut choisir d'ignorer explicitement (ce qu'on ne fait pas dans un code en production, normalement).De plus, ce n'est pas parce qu'on peut passer
nilcomme paramètre de méthode qu'il est typé. Unnildans ce genre de langage n'est pas typé, puisque rien de distingue unnild'un autre, si je puis m'exprimer ainsi. En revance, en Rust, pour garder cet exemple, unNonea un type qui estOption<T>, donc unFoo"nul" et unBar"nul" n'ont pas le même type:Option<Foo>::NonevsOption<Bar>::None. Le fait d'avoir des références nulles fait qu'il y a un typage faible localement.Pour avoir utilisé les 2 types de gestion d'erreur, je fais tout pour éviter les langages avec référence nulle qui obligent à vérifier tout le temps qu'on a bien un objet valide.