¿Cuál es la diferencia entre "x es nulo" y "x == nulo"?

En C # 7 podemos usar

if (x is null) return;

en vez de

if (x == null) return;

¿Hay alguna ventaja en usar la nueva forma (ejemplo anterior) sobre la forma antigua?

¿La semántica es diferente?

¿Es solo cuestión de gustos? Si no, ¿cuándo debo usar uno sobre el otro?

Referencia: Novedades en C # 7.0 .

Actualización: el compilador de Roslyn se ha actualizado para que el comportamiento de los dos operadores sea el mismo cuando no hay un operador de igualdad sobrecargado . Consulte el código en los resultados del compilador actual ( M1y M2en el código) que muestra lo que sucede cuando no hay un comparador de igualdad sobrecargado. Ambos tienen ahora el ==comportamiento de mejor desempeño . Si hay un comparador de igualdad sobrecargado, el código aún difiere .

Consulte las versiones anteriores del compilador de Roslyn en el análisis a continuación.

Porque nullno hay una diferencia con lo que estamos acostumbrados con C # 6. Sin embargo, las cosas se vuelven interesantes cuando cambias nulla otra constante.

Toma esto por ejemplo:

Test(1);

public void Test(object o)
{
    if (o is 1) Console.WriteLine("a");
    else Console.WriteLine("b");
}

La prueba rinde a . Si compara eso con o == (object)1lo que hubiera escrito normalmente, hace una gran diferencia. istoma en consideración el tipo al otro lado de la comparación. ¡Esta genial!

Creo que el patrón == nullvs. vs. is nullconstante es algo que es muy familiar 'por accidente', donde la sintaxis del isoperador y el operador igual producen el mismo resultado.

Como svick comentó, is nullllamadas System.Object::Equals(object, object)donde ==las llamadasceq .

IL para is:

IL_0000: ldarg.1              // Load argument 1 onto the stack
IL_0001: ldnull               // Push a null reference on the stack
IL_0002: call bool [mscorlib]System.Object::Equals(object, object) // Call method indicated on the stack with arguments
IL_0007: ret                  // Return from method, possibly with a value

IL para ==:

IL_0000: ldarg.1              // Load argument 1 onto the stack
IL_0001: ldnull               // Push a null reference on the stack
IL_0002: ceq                  // Push 1 (of type int32) if value1 equals value2, else push 0
IL_0004: ret                  // Return from method, possibly with a value

Como estamos hablando null, no hay diferencia ya que esto solo hace una diferencia en las instancias . Esto podría cambiar cuando haya sobrecargado el operador de igualdad.

Operador igual sobrecargado

De hecho, existe una diferencia en la semántica entre las dos comparaciones cuando se compara nullcon un tipo que ha sobrecargado al ==operador. foo is nullutilizará la comparación de referencia directa para determinar el resultado, mientras que foo == null, por supuesto, ejecutará el ==operador sobrecargado si existe.

En este ejemplo, he introducido un "error" en el ==operador sobrecargado , haciendo que siempre arroje una excepción si el segundo argumento es null:

void Main()
{
    Foo foo = null;

    if (foo is null) Console.WriteLine("foo is null"); // This condition is met
    if (foo == null) Console.WriteLine("foo == null"); // This will throw an exception
}

public class Foo
{
    public static bool operator ==(Foo foo1, Foo foo2)
    {
        if (object.Equals(foo2, null)) throw new Exception("oops");
        return object.Equals(foo1, foo2);
    }

    // ...
}

El código IL para foo is null utiliza la ceqinstrucción para realizar una comparación de referencia directa:

IL_0003:  ldloc.0     // foo
IL_0004:  ldnull      
IL_0005:  ceq

El código IL para foo == null utiliza una llamada al operador sobrecargado:

IL_0016:  ldloc.0     // foo
IL_0017:  ldnull      
IL_0018:  call        UserQuery+Foo.op_Equality

Entonces, la diferencia es que si lo usa ==, corre el riesgo de ejecutar código de usuario (que potencialmente puede tener problemas inesperados de comportamiento o rendimiento).

Restricción de genéricos.

El uso de la is nullconstrucción restringe el tipo a un tipo de referencia. El compilador asegura esto, lo que significa que no puede usar is nullun tipo de valor. Si tiene un método genérico, no podrá usarlo a is nullmenos que el tipo genérico esté limitado a ser un tipo de referencia.

bool IsNull<T>(T item) => item is null;                  // Compile error: CS0403
bool IsNull<T>(T item) => item == null;                  // Works
bool IsNull<T>(T item) where T : class => item is null;  // Works

Gracias a David Augusto Villa por señalar esto.