¿Por qué no hay operadores de cortocircuito elevados en `bool?`?

Question

¿Por qué el soporte bool? no se levantó && y ||? Podrían haber levantado los operadores true y false que indirectamente habrían agregado && y || levantados.

Los operadores | y & ya están levantados e implementan el Three-valued logic correcto. Pero, por supuesto, no están en cortocircuito como || y &&.

La pregunta es por qué decidieron no levantar esos operadores al crear la especificación. Entonces, "es así porque la especificación lo dice", no hay respuesta al "¿por qué?".

Al levantar true y false de manera que no es ni nulltrue ni false:

public static bool operator true(bool? x) 
{ 
    return x.HasValue && x.Value 
} 

public static bool operator false(bool? x) 
{ 
    return x.HasValue && !x.Value 
} 

Esto habría dado lugar a && y || comportarse igual que sus contrapartes no-cortocircuito. Excepto que false && anything y true || anything serían cortocircuitos (false y true no hay constantes de tiempo de compilación en estos dos ejemplos).

Esto funcionaría muy similar al DBBool example on MSDN.

No veo ningún comportamiento sorprendente o peligroso al levantar estos operadores. ¿Me he perdido algo?

He leído another SO question sobre esto, pero no encontré ninguna de las respuestas satisfactoria.

---

respuesta de Jeff Yates muestra una buena razón de por qué el levantamiento de las true/false operadores no es óptima, no explica por qué levantar && y || directamente es malo. Como el levantamiento del operador es mágico para el compilador, en casos especiales Nullable<T> no es necesario seguir las reglas de sobrecarga para tipos normales y, por lo tanto, podría ofrecer &&/|| sin levantar true.

Answer 1

false && anything es lo mismo que false. Sin embargo, si espera que false && anything sea verdadero solo si anything es falso, entonces !anything es lo que desea.

También, true || anything es el mismo que true. ... Y no estoy seguro de cómo podría hacer que devuelva falso en cualquier condición, ya que no tendría sentido que "esto o aquello" no devuelva nada.

... ¿por qué agregar peso adicional a la condición cuando todo es claro y simple como es?

No suelo ser un adepto de "porque esto es así", pero no veo la ventaja de agregar dicha funcionalidad.

Answer 2

Lo que usted propone crearía dos patrones de uso diferentes para tipos anulables.

Considere el siguiente código:

bool? a = null; 

// This doesn't currently compile but would with lifted true/false operators. 
if (a) 
{ 
} 

// Whereas this provides a consistent use of nullable types. 
if (a ?? false) 
{ 
} 

Para mantener la coherencia en el uso de tipos anulables, tiene sentido a no levantar las true y false operadores en bool. No sé si esta es la verdadera razón por la que no se hizo, pero tiene sentido para mí.

Answer 3

Ya que mostraron que el levantamiento true y false es técnicamente posible, sólo hay dos posibles respuestas a su pregunta (con "ellos" siendo la gente que escribió el compilador/spec):

1. Es un error en la especificación, es decir. ellos no pensaron en esto. (posible, pero lo dudo)
2. Pensaron que el levantamiento de los operadores de cortocircuito es potencialmente propenso a errores. Podría ser la misma forma de razonar que por qué C# está completamente basado en clases (no tiene funciones exclusivas como en C++) o por qué una sentencia como if (myNullVar) { ... } (con myNullVar siendo una referencia) no funciona en C# (pero sí en C/C++)

Creo que siempre hay un equilibrio entre hacer que un lenguaje de programación sea más potente y hacerlo menos propenso a errores.

Actualización: sólo por su interés, que es lo que el official documentation dice:

Esto no está permitido porque no está claro lo que significa nula en el contexto de un condicional.