Klabnik explica por qué no quiere parámetros con nombre en Rust

Steve Klabnik, una de las firmas históricas de Rust —pasó por el equipo central y escribió buena parte de la documentación del lenguaje—, ha publicado una entrada en su blog en la que explica por qué se opone a que Rust incorpore parámetros con nombre y argumentos por defecto. El texto arranca con la distinción de manual: parámetros son los x e y de la definición de una función, argumentos son el 5 y el 6 de la llamada. A partir de ahí repasa las florituras que otros lenguajes llevan años añadiendo encima de esa base.

El caso de Rails

El ejemplo que usa es redirect_to, de Ruby on Rails. La misma función acepta una cadena con una URL, una instancia de un modelo, un hash de opciones con acción e identificador, un mensaje flash, un código HTTP concreto o varias de esas cosas a la vez. Klabnik dice que amaba Ruby y ahora ama Rust, y que precisamente ese estilo de API es la razón por la que desconfía de que Rust lo copie: es conciso y bonito para cierto tipo de ojo, pero hace muy difícil saber qué se puede hacer con una función sin leer la documentación. Y no toda librería documenta como Rails.

Conviene separar lo que ahí va junto: tipos de argumento flexibles, hashes de opciones, valores por defecto y sintaxis con pinta de palabra clave. Su escepticismo viene de ese paquete entero, no de las etiquetas de argumento por sí solas.

Nombres, valores por defecto y sobrecarga

Los parámetros con nombre permiten escribir el nombre en la llamada, foo(x: 5, y: 6), y algunos lenguajes dejan además alterar el orden. La ventaja es la claridad en el punto de uso: un status_code=200 se lee mejor que un 200 suelto. El coste es la verbosidad. Klabnik trae un ejemplo de FastAPI en Python: el decorador get admite 23 argumentos de palabra clave, y en la propia librería hay llamadas que los pasan casi todos, uno por línea, con nombres que repiten el de la variable que se envía.

De ahí salen los argumentos opcionales y los valores por defecto, que son la razón de que esas llamadas no sean aún más largas: en el ejemplo solo se pasan cinco de esos 23 y el resto se rellena solo. En Ruby se ve en la firma, con options = {} como valor inicial. Y existe una vía para tener parámetros opcionales sin valores por defecto: la sobrecarga de funciones, que permite varias definiciones con el mismo nombre y distinta firma, y elige una según lo que se pase, como en Java.

El trasfondo no es nuevo. La propuesta de añadir parámetros con nombre a Rust lleva años parada en una incidencia del repositorio de RFC, y el debate reaparece cada cierto tiempo. Lo que Klabnik sostiene es que la comodidad en la llamada se paga en la definición: cuanto más puede hacer una firma, menos evidente resulta para quien la lee qué combinaciones son válidas y cuáles no. Queda por ver si el argumento pesa lo suficiente cuando alguien vuelva a llevar la propuesta al lenguaje.