¿Cuál es el beneficio de que el operador de asignación devuelva un valor?

Estoy desarrollando un lenguaje que tengo la intención de reemplazar tanto Javascript como PHP. (No veo ningún problema con esto. No es que ninguno de estos idiomas tenga una gran base de instalación).

Una de las cosas que quería cambiar era convertir el operador de asignación en un comando de asignación, eliminando la capacidad de hacer uso del valor devuelto.

x=1;          /* Assignment. */
if (x==1) {}  /* Comparison. */
x==1;         /* Error or warning, I've not decided yet. */
if (x=1) {}   /* Error. */

Sé que esto significaría que esas funciones de una línea que las personas C aman tanto ya no funcionarían. Pensé (con poca evidencia más allá de mi experiencia personal) que la gran mayoría de las veces que esto sucedió, realmente tenía la intención de ser una operación de comparación.

¿O es eso? ¿Hay algún uso práctico del valor de retorno del operador de asignación que no pueda ser reescrito trivialmente? (Para cualquier idioma que tenga dicho concepto).

Técnicamente, puede valer la pena conservar un poco de azúcar sintáctico, incluso si se puede reemplazar trivialmente, si mejora la legibilidad de alguna operación común. Pero la asignación como expresión no cae dentro de eso. El peligro de escribirlo en lugar de una comparación significa que rara vez se usa (a veces incluso está prohibido por las guías de estilo) y provoca una doble toma cada vez que se usa. En otras palabras, los beneficios de legibilidad son pequeños en número y magnitud.

Un vistazo a los idiomas existentes que hacen esto puede valer la pena.

• Java y C # mantienen la asignación como una expresión, pero eliminan la trampa que mencionas al requerir condiciones para evaluar los valores booleanos. En general, esto parece funcionar bien, aunque las personas se quejan ocasionalmente de que esto no permite condiciones como if (x)en lugar if (x != null)o if (x != 0)dependiendo del tipo de x.
• Python hace de la asignación una declaración adecuada en lugar de una expresión. Las propuestas para cambiar esto ocasionalmente llegan a la lista de correo de ideas de python, pero mi impresión subjetiva es que esto ocurre con menos frecuencia y genera menos ruido cada vez en comparación con otras características "faltantes" como bucles do-while, declaraciones de cambio, lambdas de varias líneas, etc.

Sin embargo, Python permite un caso especial, asignando a varios nombres a la vez: a = b = c. Esto se considera una declaración equivalente a b = c; a = b, y se usa ocasionalmente, por lo que puede valer la pena agregarlo a su idioma también (pero no me preocuparía, ya que esta adición debería ser compatible con versiones anteriores).

¿Hay algún uso práctico del valor de retorno del operador de asignación que no pueda ser reescrito trivialmente?

En general, no. La idea de que el valor de una expresión de asignación sea el valor asignado significa que tenemos una expresión que puede usarse tanto para su efecto secundario como para su valor , y que muchos consideran confusa.

Usos comunes son típicamente para hacer expresiones compactas:

x = y = z;

tiene la semántica en C # de "convertir z al tipo de y, asignar el valor convertido a y, el valor convertido es el valor de la expresión, convertir eso al tipo de x, asignar a x".

Pero ya estamos en el ámbito de los efectos secundarios impertativos en un contexto de declaración, por lo que realmente hay muy poco beneficio convincente sobre eso

y = z;
x = y;

De manera similar con

M(x = 123);

ser una taquigrafía para

x = 123;
M(x);

Nuevamente, en el código original estamos usando una expresión tanto por sus efectos secundarios como por su valor, y estamos haciendo una declaración que tiene dos efectos secundarios en lugar de uno. Ambos son malolientes; trate de tener un efecto secundario por enunciado y use expresiones para sus valores, no para sus efectos secundarios.

Estoy desarrollando un lenguaje que tengo la intención de reemplazar tanto Javascript como PHP.

Si realmente quiere ser audaz y enfatizar que la asignación es una declaración y no una igualdad, entonces mi consejo es: que sea claramente una declaración de asignación .

let x be 1;

El rojo. O

x <-- 1;

o mejor:

1 --> x;

O incluso mejor aún

1 → x;

No hay absolutamente ninguna forma de confundir ninguno de esos x == 1.

Muchos idiomas eligen la ruta para hacer que la asignación sea una declaración en lugar de una expresión, incluido Python:

foo = 42 # works
if foo = 42: print "hi" # dies
bar(foo = 42) # keyword arg

y Golang:

var foo int
foo = 42 # works
if foo = 42 { fmt.Printn("hi") } # dies

Otros idiomas no tienen asignación, sino enlaces de ámbito, por ejemplo, OCaml:

let foo = 42 in
  if foo = 42 then
    print_string "hi"

Sin embargo, letes una expresión en sí misma.

La ventaja de permitir la asignación es que podemos verificar directamente el valor de retorno de una función dentro del condicional, por ejemplo, en este fragmento de Perl:

if (my $result = some_computation()) {
  say "We succeeded, and the result is $result";
}
else {
  warn "Failed with $result";
}

Perl también incluye la declaración a ese condicional solamente, lo que lo hace muy útil. También advertirá si asigna dentro de un condicional sin declarar una nueva variable allí; if ($foo = $bar)advertirá, if (my $foo = $bar)no lo hará.

Hacer la asignación en otra declaración suele ser suficiente, pero puede traer problemas de alcance:

my $result = some_computation()
if ($result) {
  say "We succeeded, and the result is $result";
}
else {
  warn "Failed with $result";
}
# $result is still visible here - eek!

Golang depende en gran medida de los valores de retorno para la comprobación de errores. Por lo tanto, permite que un condicional tome una declaración de inicialización:

if result, err := some_computation(); err != nil {
  fmt.Printf("Failed with %d", result)
}
fmt.Printf("We succeeded, and the result is %d\n", result)

Otros lenguajes usan un sistema de tipos para no permitir expresiones no booleanas dentro de un condicional:

int foo;
if (foo = bar()) // Java does not like this

Por supuesto, eso falla cuando se usa una función que devuelve un valor booleano.

Ahora hemos visto diferentes mecanismos para defenderse contra la asignación accidental:

• No permitir la asignación como expresión
• Usar comprobación de tipo estático
• La asignación no existe, solo tenemos letenlaces
• Permitir una declaración de inicialización, no permitir la asignación de lo contrario
• No permitir la asignación dentro de un condicional sin declaración

Los he clasificado en orden de preferencia ascendente: las asignaciones dentro de las expresiones pueden ser útiles (y es simple evitar los problemas de Python al tener una sintaxis de declaración explícita y una sintaxis de argumento con nombre diferente). Pero está bien no permitirlos, ya que hay muchas otras opciones para el mismo efecto.

El código sin errores es más importante que el código conciso.

Dijiste "Pensé (con poca evidencia más allá de mi experiencia personal) que la gran mayoría de las veces que esto sucedió, realmente tenía la intención de ser una operación de comparación".

¿Por qué no arreglar el problema?

En lugar de = para asignación y == para prueba de igualdad, ¿por qué no usar: = para asignación y = (o incluso ==) para igualdad?

Observar:

if (a=foo(bar)) {}  // obviously equality
if (a := foo(bar)) { do something with a } // obviously assignment

Si desea dificultar que el programador confunda la asignación con la igualdad, entonces hágalo más difícil.

Al mismo tiempo, si REALMENTE quisiera solucionar el problema, eliminaría la vasija C que afirmaba que los booleanos solo eran enteros con nombres simbólicos predefinidos de azúcar. Hazlos un tipo completamente diferente. Entonces, en lugar de decir

int a = some_value();
if (a) {}

obligas al programador a escribir:

int a = some_value();
if (a /= 0) {} // Note that /= means 'not equal'.  This is your Ada lesson for today.

El hecho es que la asignación como operador es una construcción muy útil. No eliminamos las cuchillas de afeitar porque algunas personas se cortaron. En cambio, el rey Gillette inventó la navaja de seguridad.

Para responder realmente la pregunta, sí, hay numerosos usos de esto, aunque son un poco nicho.

Por ejemplo en Java:

while ((Object ob = x.next()) != null) {
    // This will loop through calling next() until it returns null
    // The value of the returned object is available as ob within the loop
}

La alternativa sin usar la asignación incrustada requiere lo obdefinido fuera del alcance del bucle y dos ubicaciones de código separadas que llaman a x.next ().

Ya se ha mencionado que puede asignar múltiples variables en un solo paso.

x = y = z = 3;

Este tipo de cosas es el uso más común, pero los programadores creativos siempre encontrarán más.

Ya que puedes inventar todas las reglas, ¿por qué ahora permitir que la asignación convierta un valor, y simplemente no permitir asignaciones dentro de pasos condicionales? Esto le proporciona el azúcar sintáctico para facilitar las inicializaciones, al tiempo que evita un error de codificación común.

En otras palabras, legalice esto:

a=b=c=0;

Pero haz esto ilegal:

if (a=b) ...

Por lo que parece, estás en el camino de crear un lenguaje bastante estricto.

Con eso en mente, obligar a las personas a escribir:

a=c;
b=c;

en lugar de:

a=b=c;

puede parecer una mejora para evitar que las personas hagan:

if (a=b) {

cuando tenían la intención de hacer:

if (a==b) {

pero al final, este tipo de errores son fáciles de detectar y advertir si son o no códigos legales.

Sin embargo, hay situaciones en las que hacer:

a=c;
b=c;

no significa eso

if (a==b) {

será verdad

Si c es realmente una función c (), entonces podría devolver resultados diferentes cada vez que se llama. (también podría ser computacionalmente costoso también ...)

Del mismo modo, si c es un puntero al hardware mapeado en memoria, entonces

a=*c;
b=*c;

Es probable que ambos sean diferentes, y también pueden tener efectos electrónicos en el hardware en cada lectura.

Hay muchas otras permutaciones con hardware en las que debe ser preciso sobre qué direcciones de memoria se leen, se escriben y bajo restricciones de tiempo específicas, donde hacer múltiples asignaciones en la misma línea es rápido, simple y obvio, sin los riesgos de tiempo que introducir variables temporales

El mayor beneficio para mi mente de que la asignación sea una expresión es que permite que su gramática sea más simple si uno de sus objetivos es que "todo es una expresión", un objetivo de LISP en particular.

Python no tiene esto; tiene expresiones y declaraciones, la asignación es una declaración. Pero debido a que Python define una lambdaforma como una única expresión parametrizada , eso significa que no puede asignar variables dentro de una lambda. Esto es inconveniente a veces, pero no es un problema crítico, y es el único inconveniente en mi experiencia para que la asignación sea una declaración en Python.

Una forma de permitir que la asignación, o más bien el efecto de la asignación, sea una expresión sin introducir el potencial de if(x=1)accidentes que tiene C es usar una letconstrucción similar a LISP , como la (let ((x 2) (y 3)) (+ x y))que podría evaluar en su lenguaje 5. El uso de letesta manera no tiene por qué ser una tarea técnica en su idioma, si define letcomo crear un ámbito léxico. Definido de esa manera, una letconstrucción podría compilarse de la misma manera que construir y llamar a una función de cierre anidada con argumentos.

Por otro lado, si simplemente está interesado en el if(x=1)caso, pero desea que la asignación sea una expresión como en C, tal vez solo sea suficiente elegir diferentes tokens. Asignación: x := 1o x <- 1. Comparación: x == 1. Error de sintaxis: x = 1.

Sé que esto significaría que esas funciones de una línea que las personas C aman tanto ya no funcionarían. Pensé (con poca evidencia más allá de mi experiencia personal) que la gran mayoría de las veces que esto sucedió, realmente tenía la intención de ser una operación de comparación.

En efecto. Esto no es nada nuevo, todos los subconjuntos seguros del lenguaje C ya han llegado a esta conclusión.

MISRA-C, CERT-C y así sucesivamente todas las asignaciones de prohibición dentro de las condiciones, simplemente porque es peligroso.

No existe ningún caso en el que el código que depende de la asignación dentro de las condiciones no pueda reescribirse.

Además, dichos estándares también advierten contra la escritura de código que se basa en el orden de evaluación. Asignaciones múltiples en una sola fila x=y=z;es tal caso. Si una fila con múltiples asignaciones contiene efectos secundarios (funciones de llamada, acceso a variables volátiles, etc.), no puede saber qué efecto secundario ocurrirá primero.

No hay puntos de secuencia entre la evaluación de los operandos. Por lo tanto, no podemos saber si la subexpresión yse evalúa antes o después z: es un comportamiento no especificado en C. Por lo tanto, dicho código es potencialmente poco confiable, no portátil y no conforme con los subconjuntos seguros mencionados de C.

La solución hubiera sido reemplazar el código con y=z; x=y;. Esto agrega un punto de secuencia y garantiza el orden de evaluación.

Entonces, en base a todos los problemas que esto causó en C, cualquier lenguaje moderno haría bien tanto en prohibir la asignación dentro de las condiciones, como en múltiples asignaciones en una sola fila.