L'élision, ou pourquoi 90 % des lifetimes ne s'écrivent pas Elision, or why 90% of lifetimes go unwritten

Tu écris déjà des lifetimes. Le compilateur les tait pour toi.You already write lifetimes. The compiler silences them for you.

Le numéro précédent s'est clos sur un paradoxe : si les lifetimes font si peur, pourquoi en croise-t-on si peu dans le vrai code ? Parce que le compilateur en déduit l'immense majorité tout seul — pas par magie, ni par devinette, mais par trois règles parfaitement mécaniques qu'il applique à chaque signature. C'est l'élision. La comprendre, c'est savoir exactement quand le silence suffit, et quand il faut écrire le 'a soi-même.The previous issue closed on a paradox: if lifetimes are so frightening, why do we meet so few in real code? Because the compiler infers the vast majority on its own — not by magic, nor by guessing, but through three perfectly mechanical rules it applies to every signature. That's elision. To understand it is to know exactly when silence suffices, and when you must write the 'a yourself.

fn premier_mot(s: &str) -> &str {        // aucun 'a, et pourtant ça compile
    s.split(' ').next().unwrap_or("")
}

// Ce que le compilateur lit RÉELLEMENT, en silence :
fn premier_mot<'a>(s: &'a str) -> &'a str { /* ... */ }

Pourquoi premier_mot passe, mais plus_long non.Why premier_mot passes, but plus_long doesn't.

Deux fonctions presque jumelles : toutes deux prennent du &str et renvoient du &str. La première compile sans une seule annotation ; la seconde, qu'on a vue au numéro précédent, exige un 'a. La différence n'est pas dans ce qu'elles font — c'est dans le nombre d'entrées empruntées. Là où il n'y a qu'un candidat, l'élision tranche. Là où il y en a deux sans départage, elle se tait et te rend la main.Two near-twin functions: both take &str and return &str. The first compiles without a single annotation; the second, seen last issue, demands a 'a. The difference isn't in what they do — it's in how many borrowed inputs they have. Where there's a single candidate, elision decides. Where there are two with no tie-breaker, it goes silent and hands you back control.

fn premier_mot(s: &str) -> &str { /* ... */ }
// UNE seule entrée empruntée → sa durée va à la sortie. Élidé.

fn entete(&self) -> &str { /* ... */ }
// &self présent → la durée de self va à la sortie. Élidé.

Dans les deux cas, la sortie n'a qu'une source possible : l'unique paramètre emprunté, ou &self. Aucune ambiguïté à lever — le compilateur attribue la durée et avance. C'est exactement le cas le plus fréquent dans le vrai code : une méthode qui renvoie une vue sur ses propres champs, une fonction qui découpe son unique argument.In both cases, the output has only one possible source: the single borrowed parameter, or &self. No ambiguity to resolve — the compiler assigns the duration and moves on. This is exactly the most common case in real code: a method returning a view into its own fields, a function slicing its single argument.

Trois règles, appliquées dans l'ordre. Rien d'autre.Three rules, applied in order. Nothing else.

Voici l'algorithme entier, tel qu'il est gravé dans la référence du langage. Le compilateur applique les trois règles dans l'ordre, sur la signature seule. Si, une fois les trois passées, chaque référence en sortie a reçu une durée, l'élision a réussi et tu n'écris rien. S'il en reste une sans durée, c'est E0106 — à toi d'annoter. Tout le mystère des lifetimes tient dans ces trois lignes.Here's the whole algorithm, as carved into the language reference. The compiler applies the three rules in order, on the signature alone. If, once all three have run, every output reference has a duration, elision succeeded and you write nothing. If one is left without, it's E0106 — your turn to annotate. The entire mystery of lifetimes fits in these three lines.

Règle 1 d'abord (semer les durées), puis 2 et 3 (les router vers la sortie).Rule 1 first (seed the durations), then 2 and 3 (route them to the output).

Pourquoi plus_long échoue, à la lettreWhy plus_long fails, to the letter

Déroulons : Règle 1 donne x: &'a str, y: &'b str — deux durées. Règle 2 ne s'applique pas : il y a deux entrées, pas une. Règle 3 ne s'applique pas : aucun &self. La sortie reste donc sans durée attribuée — l'algorithme s'arrête, E0106. À l'inverse, premier_mot a une seule entrée : la Règle 2 conclut. Et une méthode avec &self : la Règle 3 conclut.Let's unroll it: Rule 1 gives x: &'a str, y: &'b str — two durations. Rule 2 doesn't apply: there are two inputs, not one. Rule 3 doesn't apply: no &self. So the output is left with no duration assigned — the algorithm halts, E0106. Conversely, premier_mot has a single input: Rule 2 concludes. And a method with &self: Rule 3 concludes.

Quand l'élision réussit — mais rattache la sortie à la mauvaise donnée.When elision succeeds — but ties the output to the wrong data.

Le danger n'est pas que l'élision échoue : un échec se voit, c'est E0106, le compilateur te le dit. Le vrai piège, c'est qu'elle réussisse en produisant un contrat que tu n'avais pas en tête. La Règle 3 est la plus traître : dès qu'il y a un &self, toute sortie lui est rattachée — même si, dans le corps, elle emprunte en réalité à un paramètre. L'élision, elle, passe sans broncher ; c'est le corps qui se fait refuser ensuite, sur une contrainte de durée qui semble venir de nulle part.The danger isn't that elision fails: a failure is visible — it's E0106, the compiler tells you. The real trap is when it succeeds, producing a contract you didn't intend. Rule 3 is the most treacherous: the moment there's a &self, every output is tied to it — even if, in the body, it actually borrows from a parameter. Elision itself goes through without a murmur; it's the body that gets rejected afterwards, on a lifetime constraint that seems to come from nowhere.

impl Analyseur {
    // On VEUT renvoyer une vue dans `texte`, le paramètre.
    fn extrait(&self, texte: &str) -> &str {   // élidé...
        &texte[self.debut..self.fin]
    }
}
// Règle 3 : la sortie est rattachée à &self, PAS à texte.
// → le corps est refusé, AVANT même le premier appel :
// error: lifetime may not live long enough
//   method was supposed to return data with lifetime `'2`
//   but it is returning data with lifetime `'1`
// help: consider introducing a named lifetime parameter
//       fn extrait<'a>(&self, texte: &'a str) -> &'a str

Le corps renvoie une vue dans texte — mais l'élision, elle, ne lit pas le corps. La Règle 3 voit &self et lui attribue la sortie. Résultat : la signature promet une donnée liée à analyseur quand le corps en rend une liée à texte, et c'est le corps qui est refusé — pour une promesse que tu n'avais jamais formulée. L'erreur parle de durées anonymes, '1 et '2, là où le vrai propriétaire de la donnée est ligne. Le contrat élidé est valide — mais ce n'est pas le tien.The body returns a view into texte — but elision doesn't read the body. Rule 3 sees &self and assigns the output to it. Result: the signature promises data tied to analyseur while the body returns data tied to texte, and it's the body that gets rejected — for a promise you never made. The error talks about anonymous lifetimes, '1 and '2, where the data's real owner is ligne. The elided contract is valid — but it isn't yours.

impl Analyseur {
    // On relie explicitement la sortie au PARAMÈTRE texte
    fn extrait<'t>(&self, texte: &'t str) -> &'t str {
        &texte[self.debut..self.fin]
    }
}
// La sortie vit aussi longtemps que `texte`, indépendamment de l'analyseur.
let vue = analyseur.extrait(&ligne);   // vue suit ligne — comme voulu

On écrit le 't sur texte et sur la sortie : la durée du résultat suit désormais le paramètre, plus l'analyseur. C'est précisément le cas où l'élision ne peut pas deviner juste, parce que la bonne réponse dépend de ce que fait le corps — et qu'elle ne le lit jamais. Annoter n'est pas combattre le compilateur : c'est corriger une hypothèse par défaut qui se trouvait fausse.You write the 't on texte and on the output: the result's duration now follows the parameter, not the analyser. This is precisely the case where elision can't guess right, because the correct answer depends on what the body does — and it never reads it. Annotating isn't fighting the compiler: it's correcting a default assumption that happened to be wrong.