fkthatУважаемые зрители, кто-нибудь уже втыкает в C# 8 настолько, чтобы объяснить мне чтоэтозанах?

Тут же всё очевидно до безобразия.

Так как ты определил тип аргумента как string , а не string? , значит сравнение на null -- бессмысленно, и вызывает абсолютно закономерный warning.

Смысл от использования фичи Nullable reference types может быть достигнут только в одном единственном случае. Нужно переключить режим компилятора CS8604 с Warning на Error.

fkthatНемного поэкспериментировал, и такое впечатление, что после любого сравнения на null - не-null переменная начинает почему-то рассматриваться как nullable. Похоже, что это и вправду какой-то косяк компилятора.

Может быть и косяк, но сравнение с null заведомо не-null аргумента должен вызывать вопросы.

fkthatПозвольте заметить, неправда ваша. В-первых ворнинг вызывает не сравнение с null (я же специально в коде пометил, где именно ворнинг). Во-вторых, даже в доках указано, что использование nonnullable references не отменяет необходимости проверок на null во многих случаях. Компилятор осуществляет только статический анализ nonnullable, он никак не гарантирует, что метод не сможет быть вызван с null параметром и не вставляет никаких проверок на это.

Причина этому -- поддержка существующего кода. Верно. Вставлять проверки можно с помощью аннотаций и Fody, но в идеале писать весь проект по новым правилам полностью, а внешние библиотеки, которые еще не перешли на эти правила, использовать кастинг и проверки.


fkthatДаже в случае если все и везде включено, то комилятор все равно всего лишь выдает ворнинг, который легко можно игнорировать. Т.е. по-любому для public методов доступных извне проверки делать надо.

Именно, что основная цель -- отсутствие проверок, иначе ценности в этом нет. Кому нужны ворнинги? Нужны ошибки, которые требуется исправить, а не жалкие предупреждения, на которым всем плевать :)


fkthatВот, в этом коде, например, все с т.з. компилятора будет ок:

Это костыли :) Просто слишком поздно подсуетились. Но можно выиграть на новом проекте. Правда ещё сыровато.

fkthatМожно проще, без прагмовских извратов:

Это противоречит концепции nullable-типов, которые уже есть. Вообще принят либеральный подход, основанный на предупреждениях компилятора. Хотя я считаю надо было поступать жёстче.


fkthatНа самом деле, лучше бы они возродили свой "Code Contracts" . Статический анализ там, конечно, тормозил безбожно и работал очень далеко не всегда, но в остальном была шикарная штука.

Да чёт как-то не взлетело. Я уже много лет пользую и насаждаю JetBrains.Annotations в проектах, от чего ошибок типа Null referenced exception мы получаем намного реже, чем с попытками огородиться проверками. Проверки максимум дают информацию, но не предупреждают проблемы.

fkthat,

Вот несколько самых примитивных примеров