Tại sao chúng ta có thể nhận được cảnh báo tham chiếu null, khi tham chiếu null dường như không thể?

Đọc câu hỏi này trên HNQ, tôi tiếp tục đọc về các loại tham chiếu không thể đọc được trong C # 8 và thực hiện một số thử nghiệm.

Tôi rất ý thức rằng 9 lần trong số 10, hoặc thậm chí thường xuyên hơn, khi ai đó nói rằng "Tôi đã tìm thấy một lỗi trình biên dịch!" Đây thực sự là do thiết kế, và sự hiểu lầm của chính họ. Và kể từ khi tôi bắt đầu xem xét tính năng này chỉ ngày hôm nay, rõ ràng tôi không hiểu rõ lắm về nó. Với cách này, hãy xem mã này:

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

Sau khi đọc tài liệu tôi liên kết ở trên, tôi mong muốn s == nulldòng này đưa ra cảnh báo cho tôi sau khi tất cả srõ ràng là không thể rỗng, vì vậy việc so sánh nó với nullnó không có ý nghĩa gì.

Thay vào đó, tôi nhận được một cảnh báo trên dòng tiếp theo và cảnh báo nói rằng đó scó thể là một tài liệu tham khảo vô giá trị, mặc dù, đối với một con người, rõ ràng là không phải vậy.

Hơn nữa, cảnh báo không được hiển thị nếu chúng ta không so sánh svới null.

Tôi đã thực hiện một số Googling và tôi gặp phải sự cố GitHub , hóa ra là về một thứ hoàn toàn khác, nhưng trong quá trình tôi đã có một cuộc trò chuyện với một cộng tác viên để hiểu rõ hơn về hành vi này (ví dụ: "Kiểm tra Null thường là một cách hữu ích nói với trình biên dịch để thiết lập lại suy luận trước đó về tính vô hiệu của một biến. " ). Điều này vẫn còn cho tôi với câu hỏi chính chưa được trả lời, tuy nhiên.

Thay vì tạo ra một vấn đề GitHub mới và có khả năng chiếm thời gian của những người đóng góp dự án cực kỳ bận rộn, tôi sẽ đưa vấn đề này ra cộng đồng.

Bạn có thể vui lòng giải thích cho tôi những gì đang xảy ra và tại sao? Cụ thể, tại sao không có cảnh báo nào được tạo trên s == nullđường dây và tại sao chúng ta có CS8602khi nó dường như không thể nulltham chiếu ở đây? Nếu suy luận vô hiệu không phải là bằng chứng đạn, như luồng GitHub được liên kết gợi ý, làm thế nào nó có thể sai? Điều gì sẽ là một số ví dụ về điều đó?

Đây thực sự là một bản sao của câu trả lời mà @stuartd đã liên kết, vì vậy tôi sẽ không đi sâu vào chi tiết siêu sâu ở đây. Nhưng gốc rễ của vấn đề là đây không phải là lỗi ngôn ngữ hay lỗi trình biên dịch, mà là hành vi dự định chính xác như đã thực hiện. Chúng tôi theo dõi trạng thái null của một biến. Khi ban đầu bạn khai báo biến, trạng thái đó là NotNull vì bạn khởi tạo nó một cách rõ ràng với giá trị không phải là null. Nhưng chúng tôi không theo dõi nơi mà NotNull đến từ đâu. Điều này, ví dụ, là mã tương đương hiệu quả:

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

Trong cả hai trường hợp, bạn rõ ràng kiểm tra scho null. Chúng tôi lấy điều này làm đầu vào cho phân tích dòng chảy, giống như Mads đã trả lời trong câu hỏi này: https://stackoverflow.com/a/59328672/2672518 . Trong câu trả lời đó, kết quả là bạn nhận được một cảnh báo về lợi nhuận. Trong trường hợp này, câu trả lời là bạn nhận được một cảnh báo rằng bạn đã bỏ qua tham chiếu có thể là null.

Nó không trở nên vô giá trị, đơn giản vì chúng tôi đủ ngớ ngẩn để so sánh nó với null.

Đúng, nó thực sự làm. Để trình biên dịch. Là con người, chúng ta có thể nhìn vào mã này và rõ ràng hiểu rằng nó không thể ném ngoại lệ tham chiếu null. Nhưng cách phân tích luồng nullable được thực hiện trong trình biên dịch, nó không thể. Chúng tôi đã thảo luận về một số cải tiến cho phân tích này, trong đó chúng tôi thêm các trạng thái bổ sung dựa trên giá trị đến từ đâu, nhưng chúng tôi đã quyết định rằng điều này đã tạo ra sự phức tạp lớn cho việc triển khai không phải là một lợi ích lớn, bởi vì chỉ có những nơi duy nhất điều này sẽ hữu ích cho các trường hợp như thế này, trong đó người dùng khởi tạo một biến với một newhoặc một giá trị không đổi và sau đó kiểm tra nó cho nulldù sao đi nữa.

Nếu suy luận vô hiệu không phải là chống đạn, [..] làm sao nó có thể sai?

Tôi vui vẻ chấp nhận các tài liệu tham khảo vô giá trị của C # 8 ngay khi chúng có sẵn. Vì tôi đã quen sử dụng ký hiệu [NotNull] (v.v.) của ReSharper, tôi đã nhận thấy một số khác biệt giữa hai loại này.

Trình biên dịch C # có thể bị đánh lừa, nhưng nó có xu hướng bị lỗi ở phía thận trọng (thông thường, không phải lúc nào cũng vậy).

Để tham khảo cho khách truy cập trong tương lai, đây là những tình huống tôi thấy trình biên dịch đang khá bối rối (tôi giả sử tất cả các trường hợp này là do thiết kế):

• Null tha thứ null . Thường được sử dụng để tránh cảnh báo về quy định, nhưng giữ cho đối tượng không có giá trị. Có vẻ như muốn giữ chân bạn trong hai đôi giày.

    string s = null!; //No warning

• Phân tích bề mặt . Đối lập với ReSharper (sử dụng chú thích mã ), trình biên dịch C # vẫn không hỗ trợ đầy đủ các thuộc tính để xử lý các tham chiếu nullable.

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

Mặc dù vậy, nó cho phép sử dụng một số cấu trúc để kiểm tra tính vô hiệu cũng loại bỏ cảnh báo:

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

hoặc thuộc tính (vẫn khá tuyệt) (tìm tất cả ở đây ):

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

• Phân tích mã dễ bị ảnh hưởng . Đây là những gì bạn đã đưa ra ánh sáng. Trình biên dịch phải đưa ra các giả định để hoạt động và đôi khi chúng có vẻ phản trực giác (ít nhất là đối với con người).

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

• Rắc rối với thuốc generic . Đã hỏi ở đây và giải thích rất tốt ở đây (cùng bài viết như trước, đoạn "Vấn đề với T?"). Generics là phức tạp vì họ phải làm cho cả tài liệu tham khảo và giá trị hạnh phúc. Sự khác biệt chính là trong khi string?chỉ là một chuỗi, int?trở thành một Nullable<int>và buộc trình biên dịch xử lý chúng theo những cách khác nhau đáng kể. Cũng ở đây, trình biên dịch đang chọn đường dẫn an toàn, buộc bạn phải chỉ định những gì bạn đang mong đợi:

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

Đã giải quyết các ràng buộc:

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

Nhưng nếu chúng ta không sử dụng các ràng buộc và xóa '?' từ Dữ liệu, chúng tôi vẫn có thể đặt các giá trị null vào đó bằng từ khóa 'mặc định':

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

Cái cuối cùng có vẻ khó hơn với tôi, vì nó cho phép viết mã không an toàn.

Hy vọng điều này sẽ giúp được ai đó.