Cell / RefCell & l'interior mutability Cell / RefCell & interior mutability

Muter à travers un & partagé — en déplaçant la vérification à l'exécution.Mutate through a shared & — by moving the check to runtime.

Le numéro précédent s'est clos sur un manque : Rc partage la possession, mais en lecture seule. La règle du Vol 1 l'impose — plusieurs &T, ou un seul &mut T, jamais les deux — et plusieurs Rc sont autant d'accès partagés. Or on a parfois besoin de muter une donnée partagée : un cache, un compteur, un nœud de graphe. La mutabilité intérieure (interior mutability) est la réponse de Rust, et elle repose sur un renversement. Elle ne supprime pas la règle « aliasing XOR mutation » — elle la maintient, mais déplace sa vérification de la compilation vers l'exécution. Cell et RefCell t'autorisent à muter derrière un &, et garantissent la sûreté en surveillant les emprunts au runtime. Le prix : ce qui était une erreur de compilation devient, en cas de faute, un panic.The previous issue closed on a gap: Rc shares ownership, but read-only. Vol 1's rule requires it — several &T, or a single &mut T, never both — and several Rcs are that many shared accesses. Yet you sometimes need to mutate shared data: a cache, a counter, a graph node. Interior mutability is Rust's answer, and it rests on a reversal. It doesn't remove the 'aliasing XOR mutation' rule — it keeps it, but moves its check from compile time to runtime. Cell and RefCell let you mutate behind a &, and guarantee safety by watching borrows at runtime. The price: what was a compile error becomes, on a fault, a panic.

use std::cell::RefCell;

let compteur = RefCell::new(0);          // la donnée vit derrière une RefCell
let lecture = &compteur;                 // un accès PARTAGÉ (&), pas &mut

*lecture.borrow_mut() += 1;              // …et pourtant on mute À TRAVERS lui
println!("{}", lecture.borrow());        // 1

// la règle « un seul écrivain » tient toujours — mais elle est vérifiée
// à l'EXÉCUTION, pas à la compilation. l'enfreindre panique, au lieu de ne pas compiler.

Une méthode &self qui modifie pourtant son objet.A &self method that modifies its object anyway.

Le Vol 1 a gravé une équivalence : &self veut dire lecture seule, &mut self veut dire mutation. Tenter d'écrire dans un champ depuis une méthode &self est un E0594 sans appel. C'est précisément ce qui bloque dès qu'une donnée est partagée — par Rc, ou simplement prêtée à plusieurs endroits : on n'a que des &, donc pas le droit de muter. La mutabilité intérieure brise cette équivalence d'une manière troublante : avec un champ RefCell, une méthode &self peut modifier l'objet. La mutabilité cesse d'être une propriété de l'accès (le & vs &mut) pour devenir une propriété de la donnée elle-même — le champ porte, en son type, le droit d'être muté en place.Vol 1 carved an equivalence: &self means read-only, &mut self means mutation. Trying to write to a field from a &self method is an unappealable E0594. That's exactly what blocks the moment data is shared — by Rc, or simply lent in several places: you only have &s, so no right to mutate. Interior mutability breaks this equivalence in an unsettling way: with a RefCell field, a &self method can modify the object. Mutability stops being a property of the access (& vs &mut) and becomes a property of the data itself — the field carries, in its type, the right to be mutated in place.

struct Compteur { valeur: i32 }

impl Compteur {
    fn incrementer(&self) {        // &self : accès PARTAGÉ, lecture seule
        self.valeur += 1;          // ✕ error[E0594]: cannot assign to `self.valeur`,
    }                              //   which is behind a `&` reference
}
// pour muter, il faudrait &mut self — mais tous les appelants n'y ont pas accès
// (une donnée partagée par Rc, par exemple, ne donne que des &).

L'équivalence du Vol 1 est sans ambiguïté : derrière un &, on lit, on ne mute pas. La solution évidente — passer à &mut self — n'est pas toujours disponible : si le Compteur est partagé par Rc, ou prêté à plusieurs lecteurs, aucun appelant ne détient de &mut. On est coincé entre « la donnée est partagée » et « je dois la modifier » — les deux que le Vol 1 déclarait incompatibles.Vol 1's equivalence is unambiguous: behind a &, you read, you don't mutate. The obvious fix — switch to &mut self — isn't always available: if the Compteur is shared by Rc, or lent to several readers, no caller holds a &mut. You're stuck between 'the data is shared' and 'I must change it' — the two Vol 1 declared incompatible.

Un drapeau d'emprunt, suivi à l'exécution — et le panic qui sanctionne.A borrow flag, tracked at runtime — and the panic that sanctions.

RefCell tient, à côté de la donnée, un petit état d'emprunt : non emprunté, emprunté en partage par N lecteurs, ou emprunté en exclusivité par un écrivain. borrow() exige qu'aucun écrivain ne soit actif et incrémente le compteur de lecteurs ; borrow_mut() exige qu'aucun emprunt du tout ne soit actif et pose le verrou exclusif. Chaque garde retournée (Ref, RefMut) relâche son emprunt à sa destruction. C'est, trait pour trait, le borrow checker du Vol 1 — sauf qu'il s'exécute au runtime sur ce drapeau, au lieu d'être prouvé statiquement. Et là où le compilateur refusait de compiler, RefCell panique : la même règle, la même rigueur, un autre moment et une autre sanction.RefCell keeps, beside the data, a small borrow state: unborrowed, shared-borrowed by N readers, or exclusively borrowed by one writer. borrow() requires that no writer is active and increments the reader count; borrow_mut() requires that no borrow at all is active and sets the exclusive lock. Each returned guard (Ref, RefMut) releases its borrow when dropped. It is, trait for trait, Vol 1's borrow checker — except it runs at runtime on this flag, instead of being proven statically. And where the compiler refused to compile, RefCell panics: the same rule, the same rigor, another moment and another sanction.

let cell = RefCell::new(vec![1, 2, 3]);

let lecture = cell.borrow();          // emprunt partagé : drapeau = « lu par 1 »
let ecriture = cell.borrow_mut();     // ✕ déjà emprunté → panic à l'exécution :
//   thread 'main' panicked at src/main.rs:4:21:
//   RefCell already borrowed

// la règle « lecteurs XOR écrivain » est intacte — mais sa violation, qui était
// un refus de compilation, est devenue un panic. il faut LIBÉRER avant de muter :
drop(lecture);
let ecriture = cell.borrow_mut();     // ✓ plus aucun emprunt actif

let cache = Cell::new(0u32);
cache.set(42);                  // remplace en bloc, aucune référence prêtée
let v = cache.get();            // sort une COPIE (Cell<T> exige souvent T: Copy)
let ancien = cache.replace(7);  // échange et rend l'ancien — toujours sans &

// Cell ne prête jamais : donc rien à surveiller, jamais de panic. Mais réservé
// aux valeurs qu'on remplace en entier, pas qu'on emprunte en place.

Le réflexe Rc<RefCell<T>> qui réintroduit les bugs du Vol 1.The Rc<RefCell<T>> reflex that brings back Vol 1's bugs.

Venant d'un langage à objets, on modélise volontiers un graphe ou un arbre par des nœuds qui se pointent mutuellement — et en Rust, la traduction littérale est Rc<RefCell<Noeud>>. Rc pour le partage, RefCell pour muter à travers. Ça compile, ça marche sur les petits cas. Mais on vient de rouvrir, d'un coup, toutes les portes que le Vol 1 avait fermées : les emprunts ne sont plus vérifiés statiquement (panic possible au runtime), et les cycles de Rc fuient (Vol 6 №2). On a reconstruit, en plus lourd, le modèle à pointeurs qu'on avait quitté. Or la plupart de ces structures ont une alternative qui garde les garanties statiques : l'arène — un Vec qui possède tous les nœuds, et des indices (usize) en guise de liens.Coming from an OO language, you readily model a graph or tree as nodes pointing at one another — and in Rust, the literal translation is Rc<RefCell<Noeud>>. Rc for sharing, RefCell to mutate through. It compiles, it works on small cases. But you've just reopened, at a stroke, every door Vol 1 closed: borrows are no longer checked statically (runtime panic possible), and Rc cycles leak (Vol 6 №2). You've rebuilt, more heavily, the pointer model you'd left behind. Yet most of these structures have an alternative that keeps the static guarantees: the arena — a Vec that owns all the nodes, and indices (usize) as links.

// Le réflexe : un graphe « à la Java », tout en Rc<RefCell<...>>
type Lien = Rc<RefCell<Noeud>>;
struct Noeud { valeur: i32, voisins: Vec<Lien> }

let a: Lien = Rc::new(RefCell::new(Noeud { valeur: 1, voisins: vec![] }));
let b: Lien = Rc::new(RefCell::new(Noeud { valeur: 2, voisins: vec![] }));
a.borrow_mut().voisins.push(Rc::clone(&b));
b.borrow_mut().voisins.push(Rc::clone(&a));   // cycle → fuite (Vol 6 №2)

// parcourir en mutant : si on tient un borrow_mut() de a et qu'on retombe
// sur a via un voisin → « RefCell already borrowed », panic à l'exécution. Et le cycle fuit.

Chaque nœud est une allocation séparée, reliée aux autres par des Rc qui peuvent former des cycles (fuite), et muté par des borrow_mut() qui peuvent se chevaucher (panic). Un parcours qui mute en suivant les voisins est un champ de mines : il suffit de retomber sur un nœud déjà emprunté. On a troqué les garanties de compilation du Vol 1 contre des risques d'exécution — sans même y gagner en simplicité.Each node is a separate allocation, linked to others by Rcs that can form cycles (leak), and mutated by borrow_mut()s that can overlap (panic). A traversal that mutates while following neighbors is a minefield: you need only land on an already-borrowed node. You've traded Vol 1's compile-time guarantees for runtime risks — without even gaining simplicity.

// L'arène : les nœuds dans un Vec, les liens sont des INDICES (usize)
struct Noeud { valeur: i32, voisins: Vec<usize> }
struct Graphe { noeuds: Vec<Noeud> }           // un seul propriétaire : le Vec

impl Graphe {
    fn ajouter(&mut self, v: i32) -> usize {    // &mut classique, vérifié à la compilation
        self.noeuds.push(Noeud { valeur: v, voisins: vec![] });
        self.noeuds.len() - 1                    // l'index sert d'« identité » du nœud
    }
}
// pas de Rc, pas de RefCell, pas de cycle, pas de panic. les indices se copient
// librement, et le borrow checker statique reprend tout son pouvoir.

Un seul propriétaire — le Vec — détient tous les nœuds ; les liens deviennent de simples usize, qu'on copie sans contrainte et qui ne forment jamais de cycle de possession. La mutation passe par un &mut self ordinaire sur le graphe, vérifié à la compilation : plus de panic, plus de fuite. Bonus : les nœuds contigus en mémoire sont plus rapides à parcourir. C'est l'écho du Vol 2, où l'on remplaçait une structure à références croisées par des indices — la même leçon, appliquée aux graphes.A single owner — the Vec — holds all the nodes; links become plain usize, copied freely and never forming an ownership cycle. Mutation goes through an ordinary &mut self on the graph, checked at compile time: no more panic, no more leak. Bonus: nodes contiguous in memory are faster to traverse. It echoes Vol 2, where a cross-referencing structure was replaced by indices — the same lesson, applied to graphs.