Perché otteniamo un possibile avviso di riferimento null di dereference, quando il riferimento null non sembra essere possibile?

Dopo aver letto questa domanda su HNQ, ho continuato a leggere su Nullable Reference Tipi in C # 8 e ho fatto alcuni esperimenti.

Sono consapevole che 9 volte su 10, o anche più spesso, quando qualcuno dice "Ho trovato un bug del compilatore!" questo è in realtà di progettazione e il loro malinteso. E da quando ho iniziato a esaminare questa funzione solo oggi, chiaramente non ho una buona comprensione di essa. Con questo fatto, diamo un'occhiata a questo codice:

#nullable enable
class Program
{
    static void Main()
    {
        var s = "";
        var b = s == null; // If you comment this line out, the warning on the line below disappears
        var i = s.Length; // warning CS8602: Dereference of a possibly null reference
    }
}

Dopo aver letto la documentazione che ho collegato sopra, mi aspetto che la s == nullriga mi dia un avvertimento, dopo tutto sè chiaramente non annullabile, quindi confrontarla con nullnon ha senso.

Invece, sto ricevendo un avviso sulla riga successiva e l'avviso dice che sè possibile un riferimento null, anche se, per un essere umano, è ovvio che non lo è.

Inoltre, l'avviso non viene visualizzato se non confrontiamo scon null.

Ho fatto un po 'di googling e ho riscontrato un problema con GitHub , che si è rivelato riguardare qualcos'altro, ma nel frattempo ho avuto una conversazione con un collaboratore che ha fornito ulteriori informazioni su questo comportamento (ad esempio "I controlli null sono spesso un modo utile di dire al compilatore di ripristinare la sua precedente inferenza sulla nullità di una variabile. " ). Questo mi ha comunque lasciato senza risposta la domanda principale.

Piuttosto che creare un nuovo numero di GitHub e potenzialmente occupare il tempo dei partecipanti al progetto incredibilmente impegnati, lo sto diffondendo alla comunità.

Potresti spiegarmi cosa sta succedendo e perché? In particolare, perché sulla s == nulllinea non vengono generati avvisi e perché CS8602quando non sembra nullpossibile fare riferimento qui? Se l'inferenza di nullability non è a prova di proiettile, come suggerisce il thread GitHub collegato, come può andare storto? Quali sarebbero alcuni esempi di ciò?

Questo è effettivamente un duplicato della risposta che @stuartd ha collegato, quindi non entrerò nei dettagli super profondi qui. Ma la radice della questione è che questo non è né un bug di linguaggio né un bug del compilatore, ma il comportamento previsto è esattamente come implementato. Tracciamo lo stato null di una variabile. Quando si dichiara inizialmente la variabile, quello stato è NotNull perché lo si inizializza esplicitamente con un valore che non è null. Ma non seguiamo da dove proviene NotNull. Questo, ad esempio, è effettivamente un codice equivalente:

#nullable enable
class Program
{
    static void Main()
    {
        M("");
    }
    static void M(string s)
    {
        var b = s == null;
        var i = s.Length; // warning CS8602: Dereference of a possibly null reference
    }
}

In entrambi i casi, si verifica esplicitamente sper null. Prendiamo questo come input per l'analisi del flusso, proprio come Mads ha risposto a questa domanda: https://stackoverflow.com/a/59328672/2672518 . In quella risposta, il risultato è che ricevi un avviso sul reso. In questo caso, la risposta è che si riceve un avviso che indica di aver referenziato un riferimento eventualmente nullo.

Non diventa nullable, semplicemente perché eravamo abbastanza stupidi da confrontarlo null.

Sì, lo fa davvero. Al compilatore. Come umani, possiamo guardare questo codice e ovviamente capire che non può generare un'eccezione di riferimento null. Ma il modo in cui l'analisi del flusso nullable è implementata nel compilatore, non può. Abbiamo discusso di alcuni miglioramenti apportati a questa analisi in cui abbiamo aggiunto altri stati in base alla provenienza del valore, ma abbiamo deciso che ciò aggiungeva una grande complessità all'implementazione per non un grande guadagno, perché gli unici posti in cui ciò sarebbe utile in casi come questo, in cui l'utente inizializza una variabile con un newvalore o costante e quindi lo controlla nullcomunque.

Se l'inferenza di nullability non è a prova di proiettile, [..] come può andare storto?

Ho adottato felicemente i riferimenti nullable di C # 8 non appena erano disponibili. Dato che ero abituato a usare la notazione [NotNull] (ecc.) Di ReSharper, ho notato alcune differenze tra i due.

Il compilatore C # può essere ingannato, ma tende a errare dal lato della cautela (di solito, non sempre).

Come riferimento per i futuri visitatori, questi sono gli scenari di cui ho visto il compilatore piuttosto confuso (suppongo che tutti questi casi siano di progettazione):

• Null perdonare null . Utilizzato spesso per evitare l'avvertenza di dereference, ma mantenendo l'oggetto non annullabile. Sembra voler tenere il piede in due scarpe.

    string s = null!; //No warning

• Analisi di superficie . A differenza di ReSharper (che utilizza l' annotazione di codice ), il compilatore C # non supporta ancora una gamma completa di attributi per gestire i riferimenti nullable.

    void DoSomethingWith(string? s)
    {    
        ThrowIfNull(s);
        var split = s.Split(' '); //Dereference warning
    }

Tuttavia, consente di utilizzare alcuni costrutti per verificare la nullità che elimina anche l'avviso:

    public static void DoSomethingWith(string? s)
    {
        Debug.Assert(s != null, nameof(s) + " != null");
        var split = s.Split(' ');  //No warning
    }

o (ancora piuttosto interessante) attributi (li trovi tutti qui ):

    public static bool IsNullOrEmpty([NotNullWhen(false)] string? value)
    {
        ...
    }

• Analisi del codice sensibile . Questo è ciò che hai portato alla luce. Il compilatore deve fare ipotesi per funzionare e talvolta possono sembrare controintuitive (almeno per gli umani).

    void DoSomethingWith(string s)
    {    
        var b = s == null;
        var i = s.Length; // Dereference warning
    }

• Problemi con i generici . Chiesto qui e spiegato molto bene qui (stesso articolo di prima, paragrafo "Il problema con T?"). I generici sono complicati in quanto devono rendere felici sia i riferimenti che i valori. La differenza principale è che mentre string?è solo una stringa, int?diventa a Nullable<int>e forza il compilatore a gestirli in modi sostanzialmente diversi. Anche qui, il compilatore sta scegliendo il percorso sicuro, costringendoti a specificare cosa ti aspetti:

    public interface IResult<out T> : IResult
    {
        T? Data { get; } //Warning/Error: A nullable type parameter must be known to be a value type or non-nullable reference type.
    }

Risolti i vincoli dando:

    public interface IResult<out T> : IResult where T : class { T? Data { get; }}
    public interface IResult<T> : IResult where T : struct { T? Data { get; }}

Ma se non utilizziamo i vincoli e rimuoviamo il '?' dai dati, siamo ancora in grado di inserire valori null in esso utilizzando la parola chiave "predefinita":

    [Pure]
    public static Result<T> Failure(string description, T data = default)
        => new Result<T>(ResultOutcome.Failure, data, description); 
        // data here is definitely null. No warning though.

L'ultimo mi sembra più complicato, in quanto consente di scrivere codice non sicuro.

Spero che questo aiuti qualcuno.