Чому ми отримуємо можливе попередження про нульове посилання, коли нульове посилання видається неможливим?

Прочитавши це запитання в HNQ, я продовжив читати про Nullable Reference Types в C # 8 і зробив кілька експериментів.

Я дуже усвідомлюю, що 9 разів з 10, а то й частіше, коли хтось каже "Я знайшов помилку компілятора!" це насправді задумом і власним непорозумінням. І оскільки я почав вивчати цю особливість лише сьогодні, я ясно, що я не дуже добре її розумію. Якщо це не вдається, давайте подивимось на цей код:

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

Прочитавши документацію, до якої я посилався вище, я би сподівався, що s == nullрядок надішле мене попередженням - адже sявно нерегульований, тому порівнювати його nullне має сенсу.

Натомість я отримую попередження в наступному рядку, і попередження говорить про те, що sможлива нульова посилання, хоча для людини очевидно, що це не так.

Більше того, попередження не відображається, якщо ми не порівнюємо sїх null.

Я зробив деякий Googling, і я потрапив на проблему GitHub , яка виявилася зовсім іншою, але в процесі роботи я провів розмову з дописувачем, який дав трохи більше розуміння такої поведінки (наприклад, "Нульові перевірки часто є корисним способом сказати компілятору відновити його попереднє висновок про мінливість змінної. " ). Однак це все ще не залишило мене на головне питання без відповіді.

Замість того, щоб створити нове видання GitHub і, можливо, зайняти час надзвичайно напружених учасників проекту, я передаю це спільноті.

Не могли б ви пояснити мені, що відбувається і чому? Зокрема, чому на цьому s == nullрядку не створюються попередження , і чому ми маємо, CS8602коли це не здається, що nullтут можлива посилання? Якщо висновок про нульовість не є кульовим, як підказує пов'язана нитка GitHub, як це може піти не так? Які б це були приклади?

Це фактично дублікат відповіді, з якою пов'язував @stuartd, тому я не збираюся тут вникати у надто глибокі деталі. Але суть справи полягає в тому, що це не мовна помилка, ані помилка компілятора, але це призначена поведінка саме так, як реалізована. Відстежуємо нульовий стан змінної. Коли ви спочатку оголошуєте змінну, цей стан є NotNull, оскільки ви явно ініціалізуєте його зі значенням, яке не є нульовим. Але ми не відстежуємо, звідки взявся той NotNull. Наприклад, це фактично еквівалентний код:

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

В обох випадках ви явно перевіряєте sнаявність null. Ми сприймаємо це як вхід до аналізу потоку так само, як Мадс відповів на це запитання: https://stackoverflow.com/a/59328672/2672518 . У цій відповіді виходить, що ви отримуєте попередження про повернення. У цьому випадку відповідь полягає в тому, що ви отримуєте попередження про те, що ви скасували можливу нульову посилання.

Це не стає нульовим, просто тому, що ми були досить нерозумні, щоб порівняти його null.

Так, це насправді так. До компілятора. Як люди, ми можемо розглянути цей код і, очевидно, зрозуміти, що він не може кинути нульове виняткове посилання. Але те, як реалізується аналіз нульового потоку в компіляторі, він не може. Ми обговорювали деяку кількість вдосконалень цього аналізу, де додавали додаткові стани, виходячи з того, звідки походить цінність, але ми вирішили, що це додає великої складності в реалізації не для великої вигоди, тому що єдині місця, де це було б корисно для таких випадків, коли користувач ініціалізує змінну з a newабо постійним значенням, а потім перевіряє її на nullбудь-який вигляд .

Якщо висновок про нестабільність не є кулезахисним, [..] як воно може піти не так?

Я із задоволенням прийняв нульові посилання на C # 8, як тільки вони були доступні. Коли я звик використовувати позначення ReSharper [NotNull] (і т.д.), я помітив деякі відмінності між ними.

Компілятор C # можна обдурити, але він схильний помилятися з боку обережності (як правило, не завжди).

Як орієнтир для майбутніх відвідувачів, це такі сценарії, в яких я бачив, що компілятор дуже заплутаний (я припускаю, що всі ці випадки є дизайном):

• Ніщо прощає нуль . Часто використовується, щоб уникнути попередження про відмежування, але зберігаючи об'єкт ненульовим. Схоже, хочеться тримати ногу в двох черевиках.

    string s = null!; //No warning

• Поверхневий аналіз . На противагу ReSharper (це робить це за допомогою анотації коду ), компілятор C # досі не підтримує повний спектр атрибутів для обробки нульових посилань.

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

Це, однак, дозволяє використовувати деяку конструкцію для перевірки на нікчемність, яка також позбавляється від попередження:

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

або (ще досить класні) атрибути (знайдіть їх усіх тут ):

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

• Аналіз сприйнятливого коду . Це те, що ти показав на світ. Компілятор повинен робити припущення, щоб працювати, і іноді вони можуть здаватися контрінтуїтивними (як мінімум для людей).

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

• Проблеми з дженериками . На питання тут і пояснюється дуже добре тут ( то ж стаття , як і раніше, пункт «Питання з Т?»). Генеріки складні, тому що вони повинні робити щасливими і посилання, і цінності. Основна відмінність полягає в тому, що, хоча string?це лише рядок, int?стає a Nullable<int>і змушує компілятор обробляти їх абсолютно різними способами. Також тут компілятор вибирає безпечний шлях, змушуючи вказати, що ви очікуєте:

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

Вирішено надання обмежень:

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

Але якщо ми не будемо використовувати обмеження та видалити '?' з даних, ми все ще можемо ввести нульові значення в нього за допомогою ключового слова "за замовчуванням":

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

Останній здається мені складнішим, оскільки він дозволяє писати небезпечний код.

Сподіваюся, що це комусь допоможе.