Ссылочные типы, допускающие null, в C#: контракт компиляции, а не проверка времени выполнения

Что это

Документация C# описывает ссылочные типы, допускающие null, как группу возможностей времени компиляции. В контексте аннотаций ссылочные типы не допускают null, если не помечены ?. В контексте предупреждений компилятор анализирует состояние null: отслеживает, определённо ли выражение не равно null или может быть равно null, и предупреждает, если потенциально равное null значение разыменовывают либо присваивают цели, не допускающей null. Справочник языка прямо указывает, что разницы во время выполнения нет: string и string? — один и тот же тип .NET, и компилятор не добавляет проверок времени выполнения. Начиная с .NET 6 новые проекты задают <Nullable>enable</Nullable>; старый код остаётся вне nullable-анализа, пока не добавлено это свойство или директива #nullable enable. Анализ не заглядывает в тела вызываемых методов, поэтому сигнатуры несут атрибуты вроде [NotNullWhen(true)], [MaybeNullWhen(false)] и [MemberNotNull], описывающие постусловия. В документации также указано, что API среды выполнения .NET снабжены аннотациями начиная с .NET 5.

Почему это важно

Разработчики на Kotlin, Swift и TypeScript (strictNullChecks) ожидают, что система типов обеспечивает безопасность относительно null. В C# это слой предупреждений поверх более старой системы типов. Отсюда два следствия: предупреждения помогают, только если приводят к неудачной сборке, а параметр, не допускающий null, всё равно может получить null через рефлексию, десериализацию, сборку без nullable-аннотаций или вызывающий код с !.

Как применять

• Включите возможность во всём проекте и преобразуйте предупреждения о допустимости null в ошибки: документация параметров компилятора допускает сокращение nullable в <WarningsAsErrors>nullable</WarningsAsErrors>.
• Переводите большую кодовую базу поэтапно, как описано в документации: сначала включите предупреждения или аннотации либо добавляйте #nullable enable по одному файлу, а затем переходите к общей настройке проекта.
• Всё равно проверяйте значения на границах доверия: используйте ArgumentNullException.ThrowIfNull(x) в публичных API и считайте десериализованные объекты потенциально равными null до проверки.
• Предпочитайте атрибуты оператору !: метод TryGet с [NotNullWhen(true)] out T? value позволяет вызывающему коду использовать значение без подавления предупреждений.
• Инициализируйте не допускающие null члены в конструкторе, помечайте вспомогательные методы атрибутом [MemberNotNull(nameof(field))] либо объявляйте член required.

Подводные камни

Документация перечисляет две лазейки времени выполнения, о которых компилятор не предупреждает: значение default структуры со ссылочными полями, не допускающими null, и new string[3], элементы которого равны null до присваивания. Entity Framework Core читает аннотации, чтобы определить обязательность столбца; справочник отмечает это как исключение, влияющее на поведение. Неограниченный обобщённый T? — это не Nullable<T>; он становится им только при ограничении T как struct. Оператор ! — обещание, а не проверка, и неверное обещание превращается в NullReferenceException далеко от причины ошибки.