Mengapa kita mendapatkan peringatan referensi nol dereferensi yang mungkin, ketika referensi nol sepertinya tidak mungkin?

Setelah membaca pertanyaan ini di HNQ, saya melanjutkan membaca tentang Jenis Referensi Nullable di C # 8 , dan membuat beberapa percobaan.

Saya sangat sadar bahwa 9 kali dari 10, atau bahkan lebih sering, ketika seseorang berkata "Saya menemukan bug penyusun!" ini sebenarnya oleh desain, dan kesalahpahaman mereka sendiri. Dan karena saya mulai melihat ke fitur ini hanya hari ini, jelas saya tidak memiliki pemahaman yang sangat baik tentang itu. Dengan ini, mari kita lihat kode ini:

#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
    }
}

Setelah membaca dokumentasi yang saya tautkan di atas, saya berharap s == nullkalimat itu memberi saya peringatan — setelah semua sjelas tidak dapat dibatalkan, jadi membandingkannya dengan nulltidak masuk akal.

Alih-alih, saya mendapatkan peringatan di baris berikutnya , dan peringatan itu mengatakan bahwa situ mungkin merupakan referensi nol, meskipun, bagi manusia, jelas itu bukan.

Terlebih lagi, peringatan tersebut tidak ditampilkan jika kita tidak membandingkan suntuk null.

Saya melakukan beberapa Googling dan saya mengenai masalah GitHub , yang ternyata sepenuhnya tentang hal lain, tetapi dalam prosesnya saya melakukan percakapan dengan seorang kontributor yang memberikan beberapa wawasan lebih dalam perilaku ini (mis. "Null cheque seringkali merupakan cara yang bermanfaat. memberitahu kompiler untuk mengatur ulang kesimpulan sebelumnya tentang nullability suatu variabel. " ). Ini masih meninggalkan saya dengan pertanyaan utama yang belum terjawab.

Alih-alih menciptakan masalah GitHub baru, dan berpotensi mengambil waktu dari kontributor proyek yang sangat sibuk, saya menempatkan ini untuk komunitas.

Bisakah Anda jelaskan apa yang terjadi dan mengapa? Khususnya, mengapa tidak ada peringatan yang dihasilkan di s == nulltelepon, dan mengapa kita memiliki peringatan yang CS8602sepertinya tidak nullmungkin ada di sini? Jika inferensi nullability tidak tahan peluru, seperti yang disarankan oleh thread GitHub yang tertaut, bagaimana bisa salah? Apa yang akan menjadi contohnya?

Ini secara efektif merupakan duplikat dari jawaban yang dikaitkan @stuartd, jadi saya tidak akan membahas detail yang lebih dalam di sini. Tetapi akar masalahnya adalah bahwa ini bukan bug bahasa atau bug penyusun, tetapi perilaku yang dimaksudkan persis seperti yang diterapkan. Kami melacak status nol variabel. Ketika Anda awalnya mendeklarasikan variabel, status itu adalah NotNull karena Anda secara eksplisit menginisialisasi dengan nilai yang tidak nol. Tapi kami tidak melacak dari mana NotNull itu berasal. Ini, misalnya, adalah kode yang secara efektif setara:

#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
    }
}

Dalam kedua kasus, Anda secara eksplisit menguji suntuk null. Kami mengambil ini sebagai masukan untuk analisis aliran, seperti yang dijawab Mads dalam pertanyaan ini: https://stackoverflow.com/a/59328672/2672518 . Dalam jawaban itu, hasilnya adalah Anda mendapatkan peringatan saat kembali. Dalam hal ini, jawabannya adalah bahwa Anda mendapatkan peringatan bahwa Anda mendereferensi referensi yang mungkin nol.

Itu tidak menjadi nullable, hanya karena kami cukup bodoh untuk membandingkannya null.

Yap, sebenarnya. Ke kompiler. Sebagai manusia, kita dapat melihat kode ini dan jelas memahami bahwa itu tidak dapat membuang pengecualian referensi nol. Tetapi cara analisis aliran nullable diimplementasikan dalam kompiler, tidak bisa. Kami memang membahas sejumlah peningkatan pada analisis ini di mana kami menambahkan status tambahan berdasarkan dari mana nilai itu berasal, tetapi kami memutuskan bahwa ini menambahkan banyak kerumitan pada implementasi karena bukan banyak keuntungan, karena satu-satunya tempat di mana ini akan berguna untuk kasus-kasus seperti ini, di mana pengguna menginisialisasi variabel dengan newnilai konstan atau dan kemudian memeriksanya null.

Jika inferensi nullability tidak tahan peluru, [..] bagaimana bisa salah?

Saya dengan senang hati mengadopsi referensi nullable dari C # 8 segera setelah tersedia. Karena saya terbiasa menggunakan notasi [NotNull] (dll) ReSharper, saya memang melihat beberapa perbedaan antara keduanya.

Kompiler C # dapat dikelabui, tetapi cenderung salah di sisi hati-hati (biasanya, tidak selalu).

Sebagai referensi untuk pengunjung masa depan, ini adalah skenario yang saya lihat membuat kompiler bingung (saya menganggap semua kasus ini sesuai desain):

• Null memaafkan nol . Sering digunakan untuk menghindari peringatan dereference, tetapi menjaga objek tidak dapat dibatalkan. Sepertinya ingin tetap memakai dua sepatu.

    string s = null!; //No warning

• Analisis permukaan . Bertentangan dengan ReSharper (yang melakukannya menggunakan anotasi kode ), kompiler C # masih tidak mendukung berbagai atribut untuk menangani referensi nullable.

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

Namun, hal itu memungkinkan untuk menggunakan beberapa konstruk untuk memeriksa nullability yang juga menghilangkan peringatan:

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

atau atribut (masih sangat keren) (temukan semuanya di sini ):

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

• Analisis kode yang rentan . Inilah yang Anda kemukakan. Kompiler harus membuat asumsi untuk berfungsi dan kadang-kadang mereka mungkin tampak kontra-intuitif (untuk manusia, setidaknya).

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

• Masalah dengan obat generik . Ditanyakan di sini dan dijelaskan dengan sangat baik di sini (artikel yang sama seperti sebelumnya, paragraf "Masalah dengan T?"). Generik rumit karena mereka harus membuat referensi dan nilai-nilai bahagia. Perbedaan utama adalah bahwa sementara string?hanya string, int?menjadi Nullable<int>dan memaksa kompiler untuk menanganinya dengan cara yang sangat berbeda. Juga di sini, kompiler memilih jalur aman, memaksa Anda untuk menentukan apa yang Anda harapkan:

    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.
    }

Menyelesaikan kendala pemberian:

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

Tetapi jika kita tidak menggunakan batasan dan menghapus '?' dari Data, kami masih dapat memasukkan nilai nol di dalamnya menggunakan kata kunci 'default':

    [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.

Yang terakhir tampaknya lebih sulit bagi saya, karena memang memungkinkan untuk menulis kode yang tidak aman.

Semoga ini bisa membantu seseorang.