C# operador "==": el comportamiento del compilador con diferentes estructuras

Question

Código para ilustrar:

public struct MyStruct 
    { 
     public int SomeNumber; 
    } 

    public string DoSomethingWithMyStruct(MyStruct s) 
    { 
     if (s == null) 
      return "this can't happen"; 
     else 
      return "ok"; 
    } 

    private string DoSomethingWithDateTime(DateTime s) 
    { 
     if (s == null) 
      return "this can't happen"; // XX 
     else 
      return "ok"; 
    } 

Ahora, "DoSomethingWithStruct" falla al compilar con: "operador '==' no se puede aplicar a operandos de tipo ' MyStruct 'y' <null> '". Esto tiene sentido, ya que no tiene sentido intentar una comparación de referencia con una estructura, que es un tipo de valor.

OTOH, "DoSomethingWithDateTime" compila, pero con la advertencia del compilador: "Código inalcanzable detectado" en la línea marcada "XX". Ahora, supongo que no hay error de compilación aquí, porque la estructura DateTime sobrecarga el operador "==". Pero, ¿cómo sabe el compilador que el código es inalcanzable? p.ej. ¿Mira dentro del código que sobrecarga el operador "=="? (Esto está usando Visual Studio 2005 en caso de que haga la diferencia).

Nota: soy más curioso que nada sobre lo anterior. Normalmente, no intento usar "==" para comparar estructuras y valores nulos.

EDITAR: Trataré de simplificar mi pregunta: ¿por qué se compila "DoSomethingWithDateTime", cuando "DoSomethingWithMyStruct" no lo hace? Ambos argumentos son estructuras.

Answer 1

Sabe que una estructura nunca es nula (Nullable<T> a un lado); eso es suficiente para emitir la advertencia.

Existe un problema de compilación conocido en esta área, que surgió entre el compilador C# 2.0 y el compilador C# 3.0 (y permanece en el compilador C# 4.0 en este momento) [No estoy seguro de por qué lo está viendo VS2005, sin embargo]. La prueba de igualdad no genera una advertencia de código inalcanzable para las estructuras personalizadas con los operadores ==/!=. DateTime tiene estos operadores; tu estructura no: de ahí la diferencia.

Este problema es logged on connect, y ha sido revisado bastante recientemente por el equipo del compilador (que están dispuestos a solucionarlo cuando surge la oportunidad).

Answer 2

Como DateTime es una estructura, no puede ser nulo. Y no hay forma de anular el operador == para la estructura de tal manera que el segundo parámetro será nulo.

Answer 3

Como dijo Hun1Ahpu, nunca puede ser nulo.

Sin embargo, podría proporcionar su propio operador ==, que podría tomar un objeto como un tipo de parámetro que permitiría la compilación del código anterior.

Obviamente, lo necesitaría para hacer algo lógico.