Effectivement, je n'aurai pas du utiliser correct: disons une sémantique qui garantie un minimum de sécurité, c'est à dire que la sémantique formelle correspond à l'intuition. Lorsque ce n'est pas le cas (comme en C++ ou autres), on peut écrire du code qui a du sens (probablement), mais pas forcément le sens auquel on s'attend, d'où un bug potentiel.
En fait c’est très subjectif! ^^
Tu ne peux pas mélanger les types, tu ne peux pas mélanger les pointeurs, etc. Déjà au niveau du système de type, tout est carré, je vois vraiment pas comment tu peux foirer ton coup. D’ailleurs, il va même plus loin avec un sens contraire à l’intuition pour t’empêcher de faire de grosses conneries (je pense notamment à l’immutabilité par défaut).
Ensuite on a le match qui sera forcément exhaustif (comme on s’attend à avoir un default dans un switch), les variables qu’on passe de tâches en tâches (bon j’avoue pas forcément intuitif), les boites qui empêchent la majeure partie des types de fuites de mémoire, impossible d’écrire du code non-sûr sauf dans un bloc spécifique, presque impossible de faire des erreurs de segmentation, un maximum de truc vérifiés à la compilation (donc grâce à la syntaxe), etc.
Et puis la syntaxe familière à tout ceux qui ont fait du C (c’est à dire à peu près tout le monde), donc même s’il faut piger quelques trucs spécifiques au langage/aux langages fonctionnels, je vois mal comment on peut s’y prendre pour faire des conneries.
Si j'ai bien compris, les "conditions" de Rust, fonctionnent comme une sorte de callback: on définit une condition d'erreur C, et lorsqu'une fonction X rencontre une erreur, elle appelle C en donnant le contexte de l'erreur. Ailleurs dans la pile d'appel de X, une autre fonction va recevoir le message de C (ou bien échouer lamentablement si aucune fonction n'a préciser qu'elle voulait intercepter C) et va pouvoir faire deux choses: exécuter du code (par exemple ajouter un message d'erreur à une liste) et renvoyer une valeur par défaut/sûre/témoins. Le code va retourner à X qui va recevoir de la part C la valeur en question et continuer. La doc est très bien faites donc je ne vais pas répéter l'exemple. Mais informellement, la valeur retournée par C va indiquer à X l'action qu'il doit effectuer: par exemple abandonner le traitement, ou poursuite avec une valeur "sentinelle" (-1), ignore cette tâche (une ligne d'un fichier), etc. Mais le point le plus important, c'est que ce n'est pas X qui va choisir l'action (il va seulement l'appliquer), c'est une fonction quelque part dans la pile d'appel, ce qui permet de gérer les erreurs de façon différentes en fonction du contexte. Cela me paraît très souple lorsque c'est bien utilisé, par contre attention à ne pas générer du code incompréhensible !
Ça me fait un peu penser aux Exceptions (sans les problèmes de sûreté) mais la syntaxe est quand même assez différente et... perturbante. Ça me parait plus souple que les exceptions, mais à voir à l’utilisation.
[^] # Re: De la complexité de la gestion de la mémoire et d'autres
Posté par ariasuni . En réponse à la dépêche Présentation de Rust 0.8. Évalué à 3.
En fait c’est très subjectif! ^^
Tu ne peux pas mélanger les types, tu ne peux pas mélanger les pointeurs, etc. Déjà au niveau du système de type, tout est carré, je vois vraiment pas comment tu peux foirer ton coup. D’ailleurs, il va même plus loin avec un sens contraire à l’intuition pour t’empêcher de faire de grosses conneries (je pense notamment à l’immutabilité par défaut).
Ensuite on a le
matchqui sera forcément exhaustif (comme on s’attend à avoir undefaultdans unswitch), les variables qu’on passe de tâches en tâches (bon j’avoue pas forcément intuitif), les boites qui empêchent la majeure partie des types de fuites de mémoire, impossible d’écrire du code non-sûr sauf dans un bloc spécifique, presque impossible de faire des erreurs de segmentation, un maximum de truc vérifiés à la compilation (donc grâce à la syntaxe), etc.Et puis la syntaxe familière à tout ceux qui ont fait du C (c’est à dire à peu près tout le monde), donc même s’il faut piger quelques trucs spécifiques au langage/aux langages fonctionnels, je vois mal comment on peut s’y prendre pour faire des conneries.
Ça me fait un peu penser aux Exceptions (sans les problèmes de sûreté) mais la syntaxe est quand même assez différente et... perturbante. Ça me parait plus souple que les exceptions, mais à voir à l’utilisation.
Écrit en Bépo selon l’orthographe de 1990