entre - operadores logicos c# ejemplos

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

Question

¿Por qué no bool? soporte levantado && y || ? Podrían haber levantado los operadores true y false que hubieran agregado indirectamente levantado && y || .

Los operadores | y ya están levantados e implementan la lógica correcta de tres valores . Pero, por supuesto, no son cortocircuitos como || y && .

La pregunta es por qué decidieron no levantar a esos operadores al crear la especificación. Así que "es así porque la especificación lo dice" no es una respuesta al "por qué".

Cuando levanta true y false para que null no sea true 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 resultado en && y || comportándose igual que sus homólogos no cortocircuitos. Excepto que false && anything y true || anything true || anything cortocircuito ( false y true no son constantes de tiempo de compilación en estos dos ejemplos).

Esto funcionaría muy similar al ejemplo de DBBool en MSDN .

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

He leído otra pregunta SO sobre esto, pero ninguna de las respuestas me ha resultado satisfactoria.

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

Answer 1

Como demostró que técnicamente es posible eliminar lo true y lo false , solo hay dos respuestas posibles a su pregunta (con "ellos" son las personas que escribieron el compilador / especificación):

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

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

Actualización: Sólo para su interés, eso es lo que dice la documentación oficial :

Esto no está permitido porque no está claro qué significa nulo en el contexto de un condicional.

Answer 2

Lo que usted proponga crearía dos patrones de uso diferentes para los 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)
{
}

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

Answer 3

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.

Además, true || anything true || anything es lo mismo que true . ... Y no estoy seguro de cómo puede hacer que se vuelva 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 está claro y simple como está?

Normalmente no soy un adepto de "porque esto es así", pero no veo la ventaja de agregar dicha funcionalidad.