Avant la stabilisation des Durées de Vie Non Lexicales (NLL) dans Rust 2018, le compilateur imposait des portées lexicales strictes pour les prêts, rendant des expressions comme vec.push(vec.len()) illégales, car le prêt mutable requis par push semblait entrer en conflit avec le prêt immuable requis par len. La communauté a identifié cette restriction comme étant trop conservatrice, puisque l'accès muté n'est en réalité pas utilisé avant l'exécution du corps de la méthode, créant une fenêtre théorique où l'inspection immuable reste sûre. Cela a conduit à l'introduction des prêts en deux phases, un raffinement du vérificateur de prêts qui fait la distinction entre la réservation d'un prêt mutable et son activation réelle.
Le défi principal réside dans la conciliation de la garantie d'aliasing XOR mutation de Rust avec la conception ergonomique de l'API, en particulier lorsque l'appel d'une méthode nécessite &mut self mais que ses arguments ont besoin de &self sur le même objet. Sans traitement spécialisé, le vérificateur de prêts indiquerait cela comme une violation de la seconde règle de prêt mutable, obligeant les développeurs à séquencer manuellement les opérations avec des variables temporaires. Le problème nécessite un mécanisme qui retarde l'application de l'exclusivité mutable jusqu'au moment de la mutation réelle, tout en garantissant que les accès immuables intermédiaires ne peuvent pas survivre à la transition ou créer des références pendantes.
Les prêts en deux phases fonctionnent en considérant le prêt mutable dans un appel de méthode comme une "réservation" durant l'évaluation des arguments, n'"activant" un prêt mutable complet qu'une fois l'évaluation terminée et le contrôle entrant dans le corps de la méthode. Pendant la phase de réservation, le compilateur permet des prêts immuables limités (spécifiquement, ceux dérivés d'autoref sur le receveur) tout en suivant qu'une activation mutable est en attente. Cela est implémenté dans la vérification des prêts de MIR (Représentation Intermédiaire de Niveau Moyen), où le compilateur valide qu'aucune utilisation conflictuelle n'existe entre le point de réservation et le point d'activation, garantissant la sécurité par une analyse statique plutôt que par une instrumentation à l'exécution.
Considérez un gestionnaire de tampon réseau responsable de l'agrégation des paquets avant transmission. Le système doit ajouter un en-tête dont la taille dépend de la longueur actuelle du tampon : buffer.append_header(buffer.current_len()). Ici, append_header nécessite un accès mutable pour étendre le tampon, tandis que current_len a seulement besoin d'une inspection immuable.
Le développeur pourrait extraire la longueur dans un lien séparé avant la mutation : let len = buffer.current_len(); buffer.append_header(len);. Cette approche fonctionne dans toutes les éditions de Rust et évite totalement des règles complexes du vérificateur de prêts. Cependant, elle introduit de la verbosité et crée une fenêtre où la longueur pourrait théoriquement devenir obsolète si le code est refactorisé pour inclure la concurrence, bien que dans des contextes à un seul fil, cela soit purement un problème stylistique. Le principal inconvénient est une réduction de l'ergonomie et le potentiel pour que la variable temporaire survive à sa nécessité, encombrant la portée.
Enveloppant le tampon dans un RefCell, cela permettrait à la fois des prêts immuables et mutables à l'exécution via les méthodes borrow() et borrow_mut(). Cela élimine les conflits à la compilation en reportant les vérifications à l'exécution, pouvant potentiellement paniquer en cas de violation. Bien que flexible, cela introduit une surcharge provenant du comptage de références et de la validation à l'exécution, violant le principe d'abstraction à coût nul critique pour un code réseau à haut débit. De plus, cela transfère les erreurs des garanties de compilation à des échecs potentiels à l'exécution, réduisant la fiabilité.
L'équipe a utilisé les prêts en deux phases en structurant append_header comme une méthode prenant &mut self, faisant confiance au vérificateur de prêts NLL pour gérer automatiquement la réservation. Cela a permis d'exprimer naturellement la logique sans variables temporaires ou surcharges d'exécution. Le compilateur a vérifié que current_len se termine avant l'activation du prêt mutable, garantissant la sécurité. Cette solution a été choisie car elle maintenait des abstractions à coût nul tout en fournissant une syntaxe claire et maintenable qui reflétait précisément le flux de données prévu.
L'implémentation s'est compilée sans erreurs sur Rust 1.63+, atteignant des performances optimales identiques à celles du code séquencé manuellement. Le gestionnaire de tampon a réussi à traiter un trafic de 10Gbps sans frais d'allocation, démontrant que les prêts en deux phases résolvent le problème d'ergonomie sans compromettre les garanties de sécurité de Rust. La base de code est restée exempte de complexité de mutabilité intérieure, simplifiant les audits futurs de sécurité mémoire.
Comment le prêt en deux phases interagit-il avec les opérations de déréférencement explicites et la surcharge d'opérateurs ?
Beaucoup de candidats supposent que les prêts en deux phases s'appliquent universellement à toutes les références mutables, mais elles sont spécifiquement restreintes aux situations d'autoref dans les receveurs des appels de méthode. Lors du déréférencement explicite via *vec ou de l'utilisation de traits d'opérateurs comme IndexMut, le vérificateur de prêts n'applique pas la logique en deux phases, activant immédiatement le prêt mutable. Cette restriction existe car l'autoref de méthode fournit un point de réservation clair (le site d'appel de méthode) où le compilateur peut suivre les transitions d'état, tandis que les opérations de déréférencement arbitraires manquent de cette frontière sémantique. Comprendre cette distinction prévient la confusion quand un code ayant l'air similaire échoue à la compilation.
Pourquoi le compilateur interdit-il les prêts en deux phases lorsque le receveur implémente Drop ?
Les candidats négligent souvent que les types implémentant Drop ont des sémantiques de destructeur qui compliquent la phase de réservation. Si une réservation mutable existe lorsque un destructeur s'exécute (par exemple, à travers des panics ou un contrôle de flux complexe), l'état partiellement initialisé pourrait violer les attentes de Drop d'un self valide. Le compilateur restreint donc les prêts en deux phases sur les types ayant des destructeurs personnalisés à moins qu'ils ne soient Copy, garantissant que l'activation du prêt mutable ne puisse pas interférer avec l'exécution du code de suppression. Cela empêche des bugs subtils où la phase de réservation pourrait observer un état partiellement déplacé ou invalidé pendant le déroulement de la pile.
Qu'est-ce qui distingue la phase de "réservation" de la phase d'"activation" en termes d'opérations permises ?
Durant la phase de réservation, le compilateur n'autorise que des utilisations immuables du receveur qui découlent de l'autoref de l'appel de méthode, permettant spécifiquement l'évaluation des arguments. Cependant, les candidats manquent souvent que créer des références nommées supplémentaires au receveur ou le passer à d'autres fonctions durant l'évaluation des arguments est interdit. La phase d'activation commence précisément lorsque le contrôle entre dans le corps de la méthode, à quel moment tous les prêts immuables de l'évaluation des arguments doivent avoir pris fin. Cela crée une chronologie linéaire stricte : réservation → évaluation immuable des arguments → activation → exécution de la méthode. Violé cette séquence, comme en stockant une référence dans une variable qui survit au point d'activation, entraîne une erreur de compilation pour maintenir les garanties d'exclusivité.