loading...
Cover image for Por qué Rust no tiene Ternary Operator

Por qué Rust no tiene Ternary Operator

marioeninternet profile image Mario Martínez Originally published at dev.to Updated on ・3 min read

El operador condicional o ternario, representado como ?:, es parte de las expresiones condicionales de algunos lenguajes de programación. Su uso permite evaluar una expresión y tomar una decisión, ambas cosas en una misma línea de código.

a ? b : c

Por ejemplo, esta línea en Swift, para una app en iOS:

view.backgroundColor = lightOn ? .white : .black

“Si el valor de lightOn es verdadero, el fondo de la pantalla deberá ser color blanco. De lo contrario, será negro.”

Es la misma funcionalidad que pueden brindar las expresiones If, pero el operador ternario tiene una sintaxis mucho más compacta.

La mayoría de los lenguajes de programación populares integran su propia versión del operador ternario (https://en.wikipedia.org/wiki/%3F:#Usage), entre ellos C y C++.

Rust contaba con operador ternario en sus versiones tempranas. El equipo del Core de Rust determinó que el valor de la expresividad, el minimalismo o la elegancia no estaría por encima de otros objetivos, siendo estas tres cualidades deseables, pero subordinadas.

No tener características de más es uno de los objetivos con mayor prioridad en Rust. En ese sentido, el ternario es un operador redundante.

En enero de 2012, Brian Anderson abrió en GitHub el Issue 1698, en favor de la eliminación del operador ternario, para cumplir con el plan de aligerar al lenguaje en lo referente a características.

Miembros de la comunidad, quienes participan en, o están al tanto de, la evolución de Rust, intercambiaron ideas a favor y en contra, en el issue 1698. Pesó más la remoción del operador ternario.

Para los días finales de enero de 2012, el operador estaba fuera del lenguaje (https://github.com/rust-lang/rust/pull/1705).

No es extraño que un programador habituado a otros lenguajes encuentre que Rust es escueto en sus características, y sin estar al tanto de la idiosincrasia rustácea en un primer impulso se exprese en favor de añadiduras. En 2015, dangerrust publicó, otra vez en Github (https://github.com/rust-lang/rfcs/issues/1362), que Rust había “olvidado” incluir el ternario dentro de su conjunto de operadores, para poder crear condiciones como la siguiente:

return value == 5 ? success : failure

En respuesta, dangerrust recibió un aluvión de comentarios de personas que prefieren un lenguaje con menos “ruido”, que consideran innecesario tener múltiples maneras de hacer la misma cosa cuando ya existe una que es claramente legible.

En este punto, me resulta evidente que el Core Team de Rust y los rustáceos están en la misma sintonía, mayormente. Hay que familiarizarse con los motivos detrás del diseño de Rust como parte de la tarea de inmersión a su sintaxis.

Siendo Rust un lenguaje muy orientado a expresiones, este incorpora “implicit returns” (devolución implícita de resultados) en su diseño. Quizá quienes gusten de evaluar y devolver valores en una misma línea de código, a semejanza con el operador ternario, pueden escribir una última línea dentro de un función como sigue:

...
if value == 5 { success } else { failure }

O, cuando sea para asignar un valor a una variable:

Let howDidItGo = if value == 5 { success } else { failure };

Comunidad de Rust en México

Tuve la oportunidad de co-organizar un grupo de reuniones en Meetup, RustMX, con la finalidad de que sea uno de los canales para la comunidad en México.

El grupo tiene una cuenta en Twitter para que siempre puedas estar al tanto de eventos, contenidos y otros integrantes de la comunidad de Rust en México: @rustlang_mx.

Si eres programador o si deseas convertirte en uno, la invitación está abierta para que te sumes a la comunidad. Contarás con el apoyo de los integrantes y si eres un entusiasta de compartir tus conocimientos, quizá te puedas involucrar en este pequeño esfuerzo para extender su alcance hasta el lugar donde vives.


Nota: el texto fue publicado originalmente el 4 de febrero de 2018 en Medium y lo he migrado a Dev.to el 24 de mayo de 2019 con actualizaciones mínimas.

Discussion

pic
Editor guide