almessadi.
Retour à l'index

Le vérificateur d'emprunt de Rust pour les développeurs JavaScript_

La manière la plus simple de comprendre la propriété en Rust est d'arrêter de la comparer à la syntaxe et de commencer à la comparer à la durée de vie des objets.

Publié8 mai 2024
Temps de lecture9 min read

Ce qui rend Rust hostile aux développeurs JavaScript n'est pas la syntaxe. C'est le modèle de durée de vie.

En JavaScript, vous ne pensez généralement pas directement à qui possède la mémoire. Le runtime et le ramasse-miettes gèrent cela pour vous.

Rust impose la question dans le système de types.

Propriété en une phrase

Chaque valeur a un propriétaire, et lorsque cet propriétaire sort du scope, la valeur est abandonnée.

C'est le modèle de base.

Le compilateur applique ensuite des règles d'emprunt afin que vous ne puissiez pas accidentellement utiliser des données après qu'elles aient été déplacées ou les modifier par des références conflictuelles.

La première erreur que tout le monde voit

fn print_name(name: String) {
    println!("{}", name);
}

fn main() {
    let my_name = String::from("Alaeddine");
    print_name(my_name);
    println!("{}", my_name);
}

Ceci échoue parce que my_name est déplacé dans print_name.

Pour un développeur JavaScript, cela semble arbitraire. Pour Rust, c'est ainsi que le transfert de propriété est rendu explicite.

Emprunter au lieu de déplacer

Si la fonction a seulement besoin de lire la valeur, empruntez-la :

fn print_name(name: &str) {
    println!("{}", name);
}

fn main() {
    let my_name = String::from("Alaeddine");
    print_name(&my_name);
    println!("{}", my_name);
}

Maintenant, la propriété reste avec my_name, et la fonction reçoit une référence avec une promesse plus étroite.

Pourquoi cela existe

Le vérificateur d'emprunt ne cherche pas à vous faire souffrir. Il prévient :

  • les bugs d'utilisation après libération
  • les courses de données
  • les modèles d'aliasing invalides

dans du code qui autrement compilerait dans des langages de bas niveau et échouerait à l'exécution.

Le coût ergonomique est en amont. Le bénéfice est que toute une classe de bugs de mémoire devient des erreurs de compilation.

La meilleure façon de l’apprendre

Ne commencez pas par mémoriser les messages d'erreur.

Commencez par demander :

  • qui possède cette valeur ?
  • est-ce que je la déplace ou que je l'emprunte ?
  • est-ce que cette fonction a besoin de propriété, de mutation, ou seulement d'une référence de lecture ?

Une fois que ces questions deviennent normales, les erreurs du compilateur commencent à être perçues comme des conseils au lieu d'une punition.

Lectures supplémentaires