Antes de la estabilización de Non-Lexical Lifetimes (NLL) en Rust 2018, el compilador aplicaba estrictos alcances léxicos para los préstamos, lo que hacía que expresiones como vec.push(vec.len()) fueran ilegales porque el préstamo mutable requerido por push parecía entrar en conflicto con el préstamo inmutable requerido por len. La comunidad identificó esta restricción como excesivamente conservadora, ya que el acceso mutable no se utiliza realmente hasta que se ejecuta el cuerpo del método, creando una ventana teórica donde la inspección inmutable sigue siendo segura. Esto llevó a la introducción de préstamos en dos fases, un refinamiento del verificador de préstamos que distingue entre la reserva de un préstamo mutable y su activación real.
El desafío fundamental radica en reconciliar la garantía de aliasing XOR mutación de Rust con el diseño ergonómico de API, específicamente cuando una llamada de método requiere &mut self pero sus argumentos necesitan &self en el mismo objeto. Sin un manejo especializado, el verificador de préstamos marcaría esto como una violación de la segunda regla de préstamo mutable, obligando a los desarrolladores a secuenciar manualmente las operaciones con variables temporales. El problema requiere un mecanismo que retrase la aplicación de la exclusividad mutable hasta el momento de la mutación real, asegurando al mismo tiempo que los accesos inmutables intermedios no puedan sobrevivir a la transición ni crear referencias colgantes.
Los préstamos en dos fases operan tratando el préstamo mutable en una llamada de método como una "reserva" durante la evaluación de argumentos, solo "activándose" a un préstamo mutable completo una vez que se completa la evaluación y el control entra en el cuerpo del método. Durante la fase de reserva, el compilador permite préstamos inmutables limitados (específicamente, aquellos derivados de autoref en el receptor) mientras rastrea que una activación mutable está pendiente. Esto se implementa dentro de la verificación de préstamos de MIR (Mid-level Intermediate Representation), donde el compilador valida que no existen usos en conflicto entre el punto de reserva y el punto de activación, asegurando la seguridad a través de análisis estático en lugar de instrumentación en tiempo de ejecución.
Considera un gestor de búfer de red responsable de agregar paquetes antes de la transmisión. El sistema necesita agregar un encabezado cuyo tamaño depende de la longitud actual del búfer: buffer.append_header(buffer.current_len()). Aquí, append_header requiere acceso mutable para extender el búfer, mientras que current_len solo necesita inspección inmutable.
El desarrollador podría extraer la longitud en una vinculación separada antes de la mutación: let len = buffer.current_len(); buffer.append_header(len);. Este enfoque funciona en todas las ediciones de Rust y evita por completo las complejas reglas del verificador de préstamos. Sin embargo, introduce verbosidad y crea una ventana donde la longitud podría volverse teóricamente obsoleta si el código se refactora para incluir concurrencia, aunque en contextos de un solo hilo esta es puramente una preocupación estilística. La principal desventaja es la reducción de la ergonomía y la posibilidad de que la variable temporal sobreviva más allá de su necesidad, desordenando el alcance.
Envolver el búfer en un RefCell permitiría tanto préstamos inmutables como mutables en tiempo de ejecución a través de los métodos borrow() y borrow_mut(). Esto elimina conflictos en tiempo de compilación al posponer las verificaciones a tiempo de ejecución, potencialmente provocando pánicos en caso de violación. Si bien es flexible, esto introduce una sobrecarga por la contabilidad de referencias y la validación en tiempo de ejecución, violando el principio de abstracción de costo cero crítico para el código de red de alto rendimiento. Además, desplaza errores de garantías en tiempo de compilación a posibles fallos en tiempo de ejecución, reduciendo la fiabilidad.
El equipo utilizó préstamos en dos fases estructurando append_header como un método que toma &mut self, confiando en el verificador de préstamos NLL para manejar la reserva automáticamente. Esto permitió la expresión natural de la lógica sin variables temporales ni sobrecarga en tiempo de ejecución. El compilador verificó que current_len se completara antes de que se activara el préstamo mutable, asegurando la seguridad. Esta solución fue elegida porque mantenía abstracciones de costo cero mientras proporcionaba una sintaxis limpia y mantenible que reflejaba con precisión el flujo de datos previsto.
La implementación se compiló sin errores en Rust 1.63+, logrando un rendimiento óptimo idéntico al código secuenciado manualmente. El gestor de búfer procesó con éxito tráfico de 10Gbps sin sobrecarga de asignación, demostrando que los préstamos en dos fases resuelven el problema de ergonomía sin comprometer las garantías de seguridad de Rust. La base de código permaneció libre de la complejidad de la mutabilidad interior, simplificando futuras auditorías de seguridad de memoria.
¿Cómo interactúa el préstamo en dos fases con operaciones de desreferencia explícita y sobrecarga de operadores?
Muchos candidatos asumen que los préstamos en dos fases se aplican universalmente a todas las referencias mutables, pero están restringidos específicamente a situaciones de autoref en receptores de llamadas de método. Cuando se desreferencia explícitamente a través de *vec o se utilizan rasgos de operador como IndexMut, el verificador de préstamos no aplica la lógica de dos fases, activando inmediatamente el préstamo mutable. Esta restricción existe porque el autoref de método proporciona un claro punto de reserva (el sitio de llamada de método) donde el compilador puede rastrear las transiciones de estado, mientras que las operaciones de desreferencia arbitrarias carecen de este límite semántico. Entender esta distinción previene la confusión cuando un código que parece similar no compila.
¿Por qué prohíbe el compilador los préstamos en dos fases cuando el receptor implementa Drop?
Los candidatos a menudo pasan por alto que los tipos que implementan Drop tienen semántica de destructores que complican la fase de reserva. Si existe una reserva mutable cuando se ejecuta un destructor (por ejemplo, a través de pánicos o flujo de control complejo), el estado parcialmente inicializado podría violar las expectativas de Drop de un estado válido. Por lo tanto, el compilador restringe los préstamos en dos fases en tipos con destructores personalizados a menos que sean Copy, asegurando que la activación del préstamo mutable no pueda interferir con la ejecución de la pega de eliminación. Esto previene errores sutiles en los que la fase de reserva podría observar un estado parcialmente movido o invalidado durante la descompresión de la pila.
¿Qué distingue la fase de "reserva" de la fase de "activación" en términos de operaciones permitidas?
Durante la fase de reserva, el compilador permite solo usos inmutables del receptor que derivan del autoref de la llamada de método, permitiendo específicamente la evaluación de argumentos. Sin embargo, los candidatos a menudo pasan por alto que crear referencias nombradas adicionales al receptor o pasarlo a otras funciones durante la evaluación de argumentos está prohibido. La fase de activación comienza precisamente cuando el control entra en el cuerpo del método, en cuyo momento todos los préstamos inmutables de la evaluación de argumentos deben haber finalizado. Esto crea una línea de tiempo estrictamente lineal: reserva → evaluación inmutable de argumentos → activación → ejecución del método. Violando esta secuencia, como almacenar una referencia en una variable que sobreviva al punto de activación, resulta en un error de tiempo de compilación para mantener las garantías de exclusividad.