{"@context":"https://schema.org","@type":"FAQPage","mainEntity":[{"@type":"Question","name":"Qu'est-ce qu'un Higher-Ranked Trait Bound (HRTB) en Rust ?","acceptedAnswer":{"@type":"Answer","text":"Un Higher-Ranked Trait Bound (HRTB) permet de spécifier qu'une fonction ou un trait doit fonctionner pour tous les lifetimes possibles, pas seulement un lifetime spécifique. La syntaxe for<'a> indique que le bound doit être satisfait pour n'importe quel lifetime 'a choisi par l'appelant. Cette fonctionnalité est essentielle pour les closures et les callbacks qui doivent accepter des références avec des lifetimes variés."}},{"@type":"Question","name":"Quelle est la différence entre fn foo<'a>(f: impl Fn(&'a str)) et fn foo(f: impl for<'a> Fn(&'a str)) ?","acceptedAnswer":{"@type":"Answer","text":"Avec fn foo<'a>, le lifetime 'a est fixé par l'appelant au moment de l'appel et reste le même pour toute la durée de l'exécution. Avec for<'a>, la closure doit fonctionner pour n'importe quel lifetime, permettant de l'appeler plusieurs fois avec des références de lifetimes différents. Cette distinction est cruciale pour les APIs qui appellent une closure plusieurs fois avec des références temporaires différentes."}},{"@type":"Question","name":"Qu'est-ce que le lifetime subtyping en Rust et que signifie 'a: 'b ?","acceptedAnswer":{"@type":"Answer","text":"Le lifetime subtyping établit une relation de sous-typage entre lifetimes. La notation 'a: 'b signifie que 'a vit au moins aussi longtemps que 'b, donc 'a est un sous-type de 'b. Une référence avec un lifetime plus long peut être utilisée là où un lifetime plus court est attendu. Cette relation est covariant pour les références immutables, permettant de passer une référence avec un lifetime plus long là où un plus court suffirait."}},{"@type":"Question","name":"Qu'est-ce que la variance en Rust et comment affecte-t-elle les types génériques ?","acceptedAnswer":{"@type":"Answer","text":"La variance décrit comment la relation de sous-typage d'un type se propage à travers les constructeurs de types génériques. Un type est covariant si T<'long> est un sous-type de T<'short> quand 'long: 'short. Il est contravariant si la relation est inversée, et invariant si aucune relation de sous-typage n'existe. En Rust, les références immutables sont covariantes, les références mutables sont invariantes, et les paramètres de fonction sont contravariants."}},{"@type":"Question","name":"Pourquoi &mut T est-il invariant par rapport à T alors que &T est covariant ?","acceptedAnswer":{"@type":"Answer","text":"Une référence mutable &mut T est invariante car elle permet à la fois la lecture et l'écriture. Si elle était covariante, on pourrait écrire une valeur d'un type incorrect. Si elle était contravariante, on pourrait lire une valeur comme un type incorrect. L'invariance garantit que le type pointé correspond exactement à ce qui est attendu. Une référence immutable &T est covariante car elle ne permet que la lecture, rendant sûr d'accepter un sous-type."}},{"@type":"Question","name":"Quelle est la principale caractéristique du lifetime 'static en Rust ?","acceptedAnswer":{"@type":"Answer","text":"Le lifetime 'static indique qu'une référence peut vivre pour toute la durée d'exécution du programme. Les string literals ont automatiquement le lifetime 'static car ils sont intégrés dans le binaire. Les types owned comme String ou Vec satisfont aussi le bound T: 'static car ils ne contiennent pas de références avec des lifetimes limités. Attention à ne pas confondre 'static avec une allocation statique en mémoire."}},{"@type":"Question","name":"Quelle est la différence entre T: 'static et &'static T ?","acceptedAnswer":{"@type":"Answer","text":"Le bound T: 'static signifie que le type T ne contient aucune référence avec un lifetime non-'static, ce qui inclut tous les types owned comme String, Vec, ou i32. Le type &'static T est une référence qui doit vivre pour toute la durée du programme. Un String satisfait T: 'static mais n'est pas un &'static str. Cette distinction est importante pour les threads et les closures 'static qui exigent T: 'static, pas nécessairement des références 'static."}},{"@type":"Question","name":"Qu'est-ce que NLL (Non-Lexical Lifetimes) en Rust et quel problème résout-il ?","acceptedAnswer":{"@type":"Answer","text":"NLL (Non-Lexical Lifetimes) est une amélioration du borrow checker introduite dans Rust 2018. Avant NLL, les lifetimes étaient liés aux scopes lexicaux, ce qui causait des rejets de code valide. Avec NLL, le borrow checker analyse le flow réel du code et termine un borrow dès que la référence n'est plus utilisée, pas à la fin du scope. Cela permet d'écrire du code plus naturel sans variables temporaires artificielles."}},{"@type":"Question","name":"Dans quel cas utiliser un HRTB (for<'a>) plutôt qu'un paramètre de lifetime générique explicite ?","acceptedAnswer":{"@type":"Answer","text":"Un HRTB est nécessaire quand une closure ou fonction doit accepter des références avec des lifetimes différents à chaque appel. Par exemple, une fonction qui itère sur une collection et appelle une closure pour chaque élément avec une référence temporaire. Sans HRTB, le lifetime serait fixé au premier appel. Les HRTB sont courants avec les traits Fn, FnMut, FnOnce et les implémentations de traits pour les fonctions."}},{"@type":"Question","name":"Comment déclarer un trait avec un HRTB pour une méthode qui prend une référence ?","acceptedAnswer":{"@type":"Answer","text":"Pour déclarer un trait avec HRTB, la syntaxe utilise for<'a> dans le bound. Par exemple, pour un trait Parser avec une méthode parse prenant &'a str, le bound serait T: for<'a> Parser<'a>. Cela signifie que l'implémentation doit fonctionner pour tous les lifetimes possibles de l'input. Cette technique est utilisée dans des bibliothèques comme serde pour la désérialisation de données avec des lifetimes variables."}},{"@type":"Question","name":"Qu'est-ce que la covariance et dans quels cas s'applique-t-elle aux références en Rust ?","acceptedAnswer":{"@type":"Answer","text":"La covariance signifie que si 'long outlive 'short ('long: 'short), alors &'long T est un sous-type de &'short T. Cela s'applique aux références immutables car il est toujours sûr de traiter une référence qui vit plus longtemps comme une référence qui vit moins longtemps. Les types comme Vec, Box, et Option sont également covariants par rapport à T. Cette propriété permet une plus grande flexibilité dans le passage de références."}},{"@type":"Question","name":"Qu'est-ce que la contravariance et où apparaît-elle en Rust ?","acceptedAnswer":{"@type":"Answer","text":"La contravariance est l'inverse de la covariance : si 'long: 'short, alors fn(&'short T) est un sous-type de fn(&'long T). En Rust, la contravariance apparaît dans les positions d'arguments de fonction. Une fonction qui peut accepter n'importe quelle référence courte peut aussi accepter une référence longue. PhantomData est utilisé pour rendre un type contravariant par rapport à T quand c'est nécessaire."}},{"@type":"Question","name":"Quel est le rôle de PhantomData dans la gestion de la variance en Rust ?","acceptedAnswer":{"@type":"Answer","text":"PhantomData est un type zero-sized qui indique au compilateur qu'un type est logiquement lié à T sans contenir réellement de T. Il affecte la variance du type englobant. PhantomData rend le type covariant par rapport à T, PhantomData le rend contravariant, et PhantomData<*mut T> ou PhantomData T> le rend invariant. C'est essentiel pour les implémentations unsafe et les abstractions de bas niveau."}},{"@type":"Question","name":"Comment NLL a-t-il amélioré la gestion des emprunts dans les conditions et les boucles ?","acceptedAnswer":{"@type":"Answer","text":"Avant NLL, un emprunt dans une branche if s'étendait jusqu'à la fin du bloc englobant même si la branche n'était pas exécutée. Avec NLL, le borrow checker analyse le control flow graph et comprend que les emprunts dans des branches mutuellement exclusives ne se chevauchent pas. De même pour les boucles, un emprunt dans le corps n'empêche plus les mutations après la boucle si la référence n'est plus utilisée."}},{"@type":"Question","name":"Comment utiliser un lifetime bound sur un type générique, comme T: 'a ?","acceptedAnswer":{"@type":"Answer","text":"Le bound T: 'a signifie que toutes les références contenues dans T doivent vivre au moins aussi longtemps que 'a. C'est nécessaire quand une struct stocke à la fois un type générique T et une référence avec lifetime 'a. Si T contient des références plus courtes que 'a, cela pourrait créer des références pendantes. Ce bound garantit que T n'invalidera pas les références 'a de la struct."}},{"@type":"Question","name":"Pourquoi Cell et RefCell sont-ils invariants par rapport à T ?","acceptedAnswer":{"@type":"Answer","text":"Cell et RefCell permettent la mutabilité intérieure, ce qui signifie qu'ils peuvent modifier leur contenu même via une référence partagée. Si Cell<&'long T> pouvait être converti en Cell<&'short T>, on pourrait écrire une référence courte et la relire comme une référence longue, créant une référence pendante. L'invariance empêche cette conversion dangereuse et garantit la soundness du type."}},{"@type":"Question","name":"Comment fonctionne l'élision de lifetime avec les HRTB dans les traits Fn ?","acceptedAnswer":{"@type":"Answer","text":"Quand on écrit Fn(&str) -> &str sans annotations, Rust applique automatiquement un HRTB implicite: for<'a> Fn(&'a str) -> &'a str. Cela signifie que la closure doit fonctionner pour tous les lifetimes possibles de l'input, et le lifetime de sortie est lié à l'input. Cette élision rend le code plus concis tout en préservant la sémantique correcte pour les closures qui travaillent avec des références."}},{"@type":"Question","name":"Quel problème le lifetime subtyping résout-il lors du passage de références à des fonctions ?","acceptedAnswer":{"@type":"Answer","text":"Le lifetime subtyping permet de passer une référence avec un lifetime plus long à une fonction qui attend un lifetime plus court. Sans subtyping, il serait impossible de passer une référence 'static à une fonction attendant 'a. Cette flexibilité est essentielle pour l'ergonomie du langage, car les string literals ('static) peuvent être utilisés partout où une &str avec un lifetime quelconque est attendue."}},{"@type":"Question","name":"Comment les HRTB interagissent-ils avec les trait objects (dyn Trait) ?","acceptedAnswer":{"@type":"Answer","text":"Les trait objects avec HRTB nécessitent une attention particulière. Par exemple, Box Fn(&'a str)> crée un trait object pour une closure qui accepte des références de n'importe quel lifetime. Sans le HRTB explicite, le lifetime serait fixé au moment de la création du trait object. Les HRTB sont essentiels pour les callbacks stockés qui doivent être appelés avec des références de lifetimes variés."}},{"@type":"Question","name":"Quel est l'impact de la variance sur les collections génériques comme Vec ?","acceptedAnswer":{"@type":"Answer","text":"Vec est covariant par rapport à T, ce qui signifie que Vec<&'long str> est un sous-type de Vec<&'short str> quand 'long: 'short. Cela fonctionne car Vec ne permet pas d'insérer de nouveaux éléments à travers une référence partagée. Si Vec était invariant, il serait impossible de passer un Vec de références longues à une fonction attendant des références plus courtes, réduisant significativement la flexibilité."}}]}