Valen redefine el borrow checking con referencias flexibles
Valen's Memory Safety: A New Kind of Borrow Checking
Valen presenta un borrow checker flexible que relaja la regla 'shared-xor-mutable' a solo 'sin use-after-free', permitiendo múltiples referencias de lectura-escritura a un mismo objeto. Basado en la propuesta Group Borrowing de Nick Smith, el compilador recuerda a qué path apunta cada referencia y detecta errores en tiempo de compilación. Ya influyó en Carbon, Ante y Zeta, y ahora busca interoperar con Rust.
Group borrowing was dead before it had the chance to succeed. But I knew it had massive potential, if it could just make it into the world somehow.
- kvark
A mí me suena más a borrowing de "path" que a borrowing de "group", ¡pero la idea es genial! ¡Muy reveladora!
Un detalle menor es que no estoy seguro de por qué tenían que tener la palabra clave "in" para los sub-borrows. ¿No sería más consistente ver "entity &world.entities[?]" en lugar de "entity in world.entities[]"? Obtendríamos consistentemente el símbolo de borrow "&" y abriríamos la puerta a algunos contratos sobre qué índice (rango) se ve afectado.
- zamalek
> El borrow checking tiene la restricción "shared-xor-mutable": si tienes una referencia a un objeto, nadie más puede cambiar el objeto.
El artículo hace que esto suene como un problema. No lo es. Esta restricción te libera de pensar en ciertas clases de bugs en código concurrente; de ahí viene la "concurrencia sin miedo". R^w no se trata de lifetimes: podrías, en espíritu (no estoy seguro en la práctica), eliminarlo de Rust sin afectar en absoluto al use-after-free.
Por supuesto, significa que no puedes escribir muchos programas completamente válidos, y por eso esperaríamos que hubiera una solución mejor, pero eliminarlo no es una.
Si quieres tener que pensar en eso (y potencialmente introducir bugs), está perfectamente bien. La flexibilidad de no requerir r^w es extremadamente útil. Solo estoy aclarando esta atribución errónea.
- SleepyMyroslav
Esto se ve genial para sistemas guiados por código donde el código tiene conocimiento estático de cada path en el sistema. Podría ser estrictamente mejor para cosas como renderizado donde los tipos de renderizado están guiados por código. Como que tu mundo puede tener skybox y demás. Sin embargo, los ejemplos que asumen 'world' y 'entity' de gamedev son completamente engañosos. Porque creo que todo el mundo ha pasado a mundos guiados por datos. Piensa en la 'entity' 'advance' de los ejemplos de código como un 'entity blueprint execute'.
- melodyogonna
El origin de Mojo puede representar muchas de estas semánticas. Creo que se aprendió mucho de la propuesta de Nick, aunque no se implementara directamente. Aquí hay un ejemplo de cómo podrías representar el primer fragmento, donde dos referencias pueden actualizar la misma lista: https://godbolt.org/z/78bhzWjYM
- verdagon
Además, mientras escribía esto, se me ocurrieron un par de cosas:
* _Podríamos_ usar la sintaxis de parámetro de función `entities: &world.entities[]` en lugar de `entities in world.entities[]`.
* Los "Groups" no son realmente centrales para entender la idea, así que Path Borrowing podría ser un nombre mejor que Group Borrowing.
Se aceptan opiniones =)