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,

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

Сон Веры ПавловныКакая-то неуклюжая попытка что-то сделать так, как надо было делать ровно наоборот: non-nullable reference types с синтаксисом типа



Это сильно противоречит имеющемся синтаксису nullable типов. Изначально мне тоже казалось, что non-nullable лучший вариант, и может уживаться с текущим кодом. Но нет. Библиотеки должны быть обратно совместимы.

А string! это совершенно новый тип, его протаскивать надо везде. В аргументах, в свойствах и локальных переменных. Поэтому не катит.

SiemarglБезотносительно C#8, вместо string отлично передается null, как объектный тип )

Попытка подстелить соломку ?

Статическая проверка типов. Всё по феншую. Изначально ссылочные типы шли вразрез с этой идеей.

ЕвгенийВНи каких вопросов :)



Это костыль )

ЕвгенийВstring? тоже надо, я выше давал ссылку, где чувак описывает случаи.

ну ок, смотрим:




Если бы МС пошли на такое, это был бы знатный фейл. Хорошо, что не облажались )

ЕвгенийВНе костыль. Сам недавно чудом узнал, что если у структуры переопределен == то на сравнение с null компилятор не ругается )

Собственно в этом и есть костыль, реализованный через переопределение )

Сон Веры ПавловныhVosttА string! это совершенно новый тип
Ну да, аналогично было, когда вводились nullable value types.

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

Сон Веры ПавловныЗачем? Когда вводились nullable value types, никто везде массово не менял int на int?, и не протаскивал Nullable<T> везде.

Не скажи. Менял object на Nullable<T>. И протаскивал :)

Сон Веры ПавловныСтарая остается на своем месте, и с ней работают по-старому.

Обратная совместимость должна быть не только синтаксическая, но и семантическая.

int => int?
string => string?

логично? да.

int => int?
!string => string

херень какая-то. особенно для классов и структур.