C'est vrai que les borrowing rules sont assez contraignantes pour la conception d'une application. En contrepartie, elles offrent un certain nombre de garanties à l'exécution, ce qui élimine toute une classe de bugs potentiels (et de failles de sécurité).
Est-ce que le rapport contraintes/gains est si favorable que ça, à la lecture de ton post de blog, je n'en suis pas certain. Si je lis ce que tu as écrit, implémenter un simple observateur est rendu complexe alors que ce n'est pas vraiment le plus dur des patrons de conception. Il y a des langages qui offrent des garanties sans pour autant se mettre en travers de la route du programmeur en permanence.
Pour nuancer, note que le comportement est également indéfini en C++
Oui, c'est vrai, mais C++ n'a jamais dit qu'il garantissait les programmes et en particulier celui là. C'est ce que je veux dire quand je dis qu'il ne promet pas la lune. En gros, C++ te dit : «si tu fais de la merde dans ton code, attends toi à avoir de la merde à l'exécution, éventuellement pas de la même couleur».
[^] # Re: Gnirehtet réécrit en Rust
Posté par rewind (Mastodon) . En réponse au journal Du reverse tethering, en Rust. Évalué à 5.
Est-ce que le rapport contraintes/gains est si favorable que ça, à la lecture de ton post de blog, je n'en suis pas certain. Si je lis ce que tu as écrit, implémenter un simple observateur est rendu complexe alors que ce n'est pas vraiment le plus dur des patrons de conception. Il y a des langages qui offrent des garanties sans pour autant se mettre en travers de la route du programmeur en permanence.
Oui, c'est vrai, mais C++ n'a jamais dit qu'il garantissait les programmes et en particulier celui là. C'est ce que je veux dire quand je dis qu'il ne promet pas la lune. En gros, C++ te dit : «si tu fais de la merde dans ton code, attends toi à avoir de la merde à l'exécution, éventuellement pas de la même couleur».