C # va bene con il confronto dei tipi di valore con null

Mi sono imbattuto in questo oggi e non ho idea del motivo per cui il compilatore C # non genera un errore.

Int32 x = 1;
if (x == null)
{
    Console.WriteLine("What the?");
}

Sono confuso su come x potrebbe mai essere nullo. Soprattutto perché questa assegnazione genera sicuramente un errore del compilatore:

Int32 x = null;

È possibile che x possa diventare nullo, Microsoft ha appena deciso di non inserire questo controllo nel compilatore o è stato perso completamente?

Aggiornamento: dopo aver manipolato il codice per scrivere questo articolo, improvvisamente il compilatore ha avvertito che l'espressione non sarebbe mai stata vera. Adesso sono davvero perso. Ho inserito l'oggetto in una classe e ora l'avvertimento è sparito ma è rimasto con la domanda, un tipo di valore può finire per essere nullo.

public class Test
{
    public DateTime ADate = DateTime.Now;

    public Test ()
    {
        Test test = new Test();
        if (test.ADate == null)
        {
            Console.WriteLine("What the?");
        }
    }
}

Questo è legale perché la risoluzione del sovraccarico dell'operatore ha un unico migliore operatore da scegliere. È presente un operatore == che accetta due int nullable. Il locale int è convertibile in un int nullable. Il valore letterale null è convertibile in un int nullable. Pertanto questo è un utilizzo legale dell'operatore == e risulterà sempre falso.

Allo stesso modo, ti permettiamo anche di dire "if (x == 12.6)", che sarà sempre falso. L'int locale è convertibile in double, il letterale è convertibile in double e ovviamente non saranno mai uguali.

Non è un errore, poiché c'è una int?conversione ( ); genera un avviso nell'esempio fornito:

Il risultato dell'espressione è sempre "false" poiché un valore di tipo "int" non è mai uguale a "null" di tipo "int?"

Se controlli l'IL, vedrai che rimuove completamente il ramo irraggiungibile - non esiste in una build di rilascio.

Si noti tuttavia che non genera questo avviso per strutture personalizzate con operatori di uguaglianza. Era usato nella 2.0, ma non nel compilatore 3.0. Il codice è ancora rimosso (quindi sa che il codice non è raggiungibile), ma non viene generato alcun avviso:

using System;

struct MyValue
{
    private readonly int value;
    public MyValue(int value) { this.value = value; }
    public static bool operator ==(MyValue x, MyValue y) {
        return x.value == y.value;
    }
    public static bool operator !=(MyValue x, MyValue y) {
        return x.value != y.value;
    }
}
class Program
{
    static void Main()
    {
        int i = 1;
        MyValue v = new MyValue(1);
        if (i == null) { Console.WriteLine("a"); } // warning
        if (v == null) { Console.WriteLine("a"); } // no warning
    }
}

Con l'IL (per Main) - nota che tutto tranne MyValue(1)(che potrebbe avere effetti collaterali) è stato rimosso:

.method private hidebysig static void Main() cil managed
{
    .entrypoint
    .maxstack 2
    .locals init (
        [0] int32 i,
        [1] valuetype MyValue v)
    L_0000: ldc.i4.1 
    L_0001: stloc.0 
    L_0002: ldloca.s v
    L_0004: ldc.i4.1 
    L_0005: call instance void MyValue::.ctor(int32)
    L_000a: ret 
}

questo è fondamentalmente:

private static void Main()
{
    MyValue v = new MyValue(1);
}

Il fatto che un confronto non possa mai essere vero non significa che sia illegale. Tuttavia, no, un tipo di valore può mai essere null.

No, Int32 xnon lo diventerò mai null.

Se stai confrontando un int con null, è applicabile l'operatore di confronto che accetta due int.

"Perché un confronto di un tipo di valore con null è un avviso?" l'articolo ti aiuterà.

Un tipo di valore non può essere null, sebbene possa essere uguale a null(considera Nullable<>). Nel tuo caso la intvariabile e nullsono implicitamente cast Nullable<Int32>e confrontati.

Sospetto che il tuo particolare test sia stato ottimizzato dal compilatore quando genera l'IL poiché il test non sarà mai falso.

Nota a margine: è possibile che un Int32 nullable usi Int32? x invece.

Immagino che questo sia perché "==" è uno zucchero di sintassi che in realtà rappresenta la chiamata al System.Object.Equalsmetodo che accetta il System.Objectparametro. Null dalla specifica ECMA è un tipo speciale da cui è ovviamente derivato System.Object.

Ecco perché c'è solo un avvertimento.

[MODIFICATO: ha trasformato gli avvisi in errori e ha reso gli operatori espliciti su nullable piuttosto che sulla stringa hack.]

Secondo il suggerimento intelligente di @ supercat in un commento sopra, i seguenti overload di operatori consentono di generare un errore sui confronti del tipo di valore personalizzato con null.

Implementando operatori che confrontano con le versioni nullable del tuo tipo, l'uso di null in un confronto corrisponde alla versione nullable dell'operatore, che ti consente di generare l'errore tramite l'attributo Obsolete.

Fino a quando Microsoft non ci restituirà il nostro avviso del compilatore, vado con questa soluzione alternativa, grazie @supercat!

public struct Foo
{
    private readonly int x;
    public Foo(int x)
    {
        this.x = x;
    }

    public override string ToString()
    {
        return string.Format("Foo {{x={0}}}", x);
    }

    public override int GetHashCode()
    {
        return x.GetHashCode();
    }

    public override bool Equals(Object obj)
    {
        return x.Equals(obj);
    }

    public static bool operator ==(Foo a, Foo b)
    {
        return a.x == b.x;
    }

    public static bool operator !=(Foo a, Foo b)
    {
        return a.x != b.x;
    }

    [Obsolete("The result of the expression is always 'false' since a value of type 'Foo' is never equal to 'null'", true)]
    public static bool operator ==(Foo a, Foo? b)
    {
        return false;
    }
    [Obsolete("The result of the expression is always 'true' since a value of type 'Foo' is never equal to 'null'", true)]
    public static bool operator !=(Foo a, Foo? b)
    {
        return true;
    }
    [Obsolete("The result of the expression is always 'false' since a value of type 'Foo' is never equal to 'null'", true)]
    public static bool operator ==(Foo? a, Foo b)
    {
        return false;
    }
    [Obsolete("The result of the expression is always 'true' since a value of type 'Foo' is never equal to 'null'", true)]
    public static bool operator !=(Foo? a, Foo b)
    {
        return true;
    }
}

Penso che la migliore risposta al motivo per cui il compilatore lo accetta sia per le classi generiche. Considera la seguente classe ...

public class NullTester<T>
{
    public bool IsNull(T value)
    {
        return (value == null);
    }
}

Se il compilatore non accetta confronti con i nulltipi di valore, allora essenzialmente interromperà questa classe, avendo un vincolo implicito collegato al suo parametro di tipo (cioè funzionerebbe solo con i tipi non basati sul valore).

Il compilatore ti consentirà di confrontare qualsiasi struttura che implementa ==con null. Ti consente anche di confrontare un int con null (riceverai un avviso però).

Ma se disassembli il codice vedrai che il confronto viene risolto quando il codice viene compilato. Quindi, ad esempio, questo codice (dove Fooè implementata una struttura ==):

public static void Main()
{
    Console.WriteLine(new Foo() == new Foo());
    Console.WriteLine(new Foo() == null);
    Console.WriteLine(5 == null);
    Console.WriteLine(new Foo() != null);
}

Genera questo IL:

.method public hidebysig static void  Main() cil managed
{
  .entrypoint
  // Code size       45 (0x2d)
  .maxstack  2
  .locals init ([0] valuetype test3.Program/Foo V_0)
  IL_0000:  nop
  IL_0001:  ldloca.s   V_0
  IL_0003:  initobj    test3.Program/Foo
  IL_0009:  ldloc.0
  IL_000a:  ldloca.s   V_0
  IL_000c:  initobj    test3.Program/Foo
  IL_0012:  ldloc.0
  IL_0013:  call       bool test3.Program/Foo::op_Equality(valuetype test3.Program/Foo,
                                                           valuetype test3.Program/Foo)
  IL_0018:  call       void [mscorlib]System.Console::WriteLine(bool)
  IL_001d:  nop
  IL_001e:  ldc.i4.0
  IL_001f:  call       void [mscorlib]System.Console::WriteLine(bool)
  IL_0024:  nop
  IL_0025:  ldc.i4.1
  IL_0026:  call       void [mscorlib]System.Console::WriteLine(bool)
  IL_002b:  nop
  IL_002c:  ret
} // end of method Program::Main

Come potete vedere:

Console.WriteLine(new Foo() == new Foo());

È tradotto in:

IL_0013:  call       bool test3.Program/Foo::op_Equality(valuetype test3.Program/Foo,
                                                               valuetype test3.Program/Foo)

Mentre:

Console.WriteLine(new Foo() == null);

Viene tradotto in falso:

IL_001e:  ldc.i4.0