Functional C#: Non-nullable reference types (ненулевые ссылочные типы)

[impwx]

Получается, что все проверки на null, даже будучи автоматически добавленными в код, выполняются все равно в рантайме.
Не лучше ли использовать Resharper с аннотациями, или Code Contracts, чтобы получить аналогичные проверки во время компиляции?

[vkhorikov]

Не совсем так. Проверка на нал действительно идет в ран-тайме, но мы получаем ошибку компилятора в случае если используем нулевую ссылку там где подразумевалась ненулевая.
Code annotations от решарпера мне не нравятся тем, что
1) Это всего лишь warning
2) Используется opt-in схема. Т.е. все типы по умолчанию нулевые. По-хорошему нам нужно обратное поведение — сделать все типы по умолчанию ненулевыми и затем opt-out в случае если какой-то из них нулевой.

Но вообще Code annotations и Code Contracts — тоже вполне себе хорошая альтернатива

[impwx]

1. Можно настроить, чтобы предупреждение считалось ошибкой.
2. Да, так вроде бы нельзя — атрибуты все равно нужны.

Кстати, правильно ли я понял из ваших примеров, что проверяется только значение полей?
Значит, если сам объект будет нулевым, то Null Reference все равно возникнет?

var customer = CustomerService.GetCustomer(); // вдруг вернуло Null?
Console.WriteLine(customer.Name); // все равно будет NRE

[vkhorikov]

1. Согласен

Проверяются все входящие и выходящие значения. Т.е. в вашем примере NRE будет тут:

var customer = CustomerService.GetCustomer(); // будет NRE
Console.WriteLine(customer.Name);

[alexanderzaytsev]

>2. Да, так вроде бы нельзя — атрибуты все равно нужны.

Можно github.com/ulrichb/ImplicitNullability

[vkhorikov]

Еще хотел добавить. Пожалуй главный плюс подхода с Maybe для меня в том, что он улучшает читаемость кода благодаря тому, что мы разделяем нулевые и ненулевые типы.

[DrReiz]

Зачем необходима борьба с null-ом? Если достаточно написать: Console.WriteLine(customer?.Name).

[impwx]

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

[DrReiz]

Null reference затруднительно отлаживать в mutable-окружении. В таком окружении бывает затруднительно установить место появления null-а. В immutable-коде такой проблемы нет из-за прозрачности потоков данных.

[divan-9th]

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

[Trueteller]

Maybe вполне можно использовать и без Fody, с сочетанием соглашения не возвращать null и ручных проверок.
Мне больше нравится реализация Maybe на основе IEnumerable: очень удобно использовать в LINQ выражениях.
Стоит отметить, что в F# Maybe называется «option».