Очередная статья о C# 7 заставила задуматься: а в чём профит от non-null типов? То, что null — это ошибка, очевидно. Но разве можно не намокнуть, "запретив дождь"?!
Ведь null — это и есть индикатор, что что-то пошлó не так! Просто "взрыв на присвоении null" ничего не даст — нужно смотреть глубже в алгоритм и делать больше проверок/диагностик, чтобы null не вылезал, когда уже слишком поздно. Другими словами, non-null типы просто бесполезны!
Если вы поняли мою идею (или её ошибочность), отпишитесь — интересная тема.

Здравствуйте, Kolesiki, Вы писали:

K>Очередная статья о C# 7 заставила задуматься: а в чём профит от non-null типов? То, что null — это ошибка, очевидно. Но разве можно не намокнуть, "запретив дождь"?!

Кэп: в api прописываешь, где конкретно ожидаешь null, компилятор предупреждает о возможном null ref exception при попытке обратиться к nullable value без проверки на null.

Для всего остального компилятор предупреждает о попытке запихнуть null куда не надо.
Включаем конкретные предупреждения в список threat as errors — получаем на порядок меньше шансов отхватить null где не надо.
Разумеется, от намеренного головотяпства со взломом оно не спасёт, но общая температура по больнице должна слегка выправиться.

А, да, статью закопать обратно. Автор ещё дольше бы спал — non-null ещё летом (или в конце весны? лень проверять) в восьмой шарп перенесли.

Здравствуйте, Kolesiki, Вы писали:

То, что null — это ошибка, очевидно.

А почему? Или при запуске программы нужно создать все (даже в данный момент не нужные) объекты, которые потом присвоить всем ссылкам в программе? И сколько это будет запускаться и сколько памяти сожрет?

Здравствуйте, aloch, Вы писали:

A>Здравствуйте, Kolesiki, Вы писали:

A> То, что null — это ошибка, очевидно.

A>А почему? Или при запуске программы нужно создать все (даже в данный момент не нужные) объекты, которые потом присвоить всем ссылкам в программе? И сколько это будет запускаться и сколько памяти сожрет?
Можно для каждого класcа, по аналогии со String создавать пустой Empty

Здравствуйте, Serginio1, Вы писали:

S> Можно для каждого класcа, по аналогии со String создавать пустой Empty

А что это даст (кроме замедления загрузки)? Что делать при обращении к Empty — бросать EmptyReferenceException? Чем это лучше null?

Здравствуйте, Kolesiki, Вы писали:

K>Ведь null — это и есть индикатор, что что-то пошлó не так! Просто "взрыв на присвоении null" ничего не даст — нужно смотреть глубже в алгоритм и делать больше проверок/диагностик, чтобы null не вылезал, когда уже слишком поздно. Другими словами, non-null типы просто бесполезны!

Тут прикол в том, что "взрыва" быть не должно — проверка на null должна происходить статически. То есть на этапе выполнения сюрпризов не должно быть. Примерно так же, как сейчас нельзя присвоить null в int. Но это в теории, как там хотят в си-краше сделать, я хз.

Здравствуйте, Kolesiki, Вы писали:

K>То, что null — это ошибка, очевидно.
Вот на этом месте надо включить мозг.
Тысячи мест в самом .NET FW и миллионы в остальном коде, где null — корректное значение, в остальных случаях ошибка.

K>Ведь null — это и есть индикатор, что что-то пошлó не так! Просто "взрыв на присвоении null" ничего не даст — нужно смотреть глубже в алгоритм и делать больше проверок/диагностик, чтобы null не вылезал, когда уже слишком поздно.
А с другой стороны в методах уменьшится количество проверок на null, это еще и немного скорость работы увеличит, так как будет контролироваться компилятором и не рантаймом.

Причем в 90+% случаев в алгоритме невозможно появление null, поэтому легко заменить nullable на non-nullable тип. В оставшихся 10% компилятор заставит вас написать код, который явно обрабатывает null, что лучше, чем получить ошибку в рантайме.

Здравствуйте, Serginio1, Вы писали:

A>> То, что null — это ошибка, очевидно.
A>>А почему? Или при запуске программы нужно создать все (даже в данный момент не нужные) объекты, которые потом присвоить всем ссылкам в программе? И сколько это будет запускаться и сколько памяти сожрет?
S> Можно для каждого класcа, по аналогии со String создавать пустой Empty
Тогда, если забыть проинициализировать, программа вместно честного падения будет продолжать работать и где-то совсем не там выдаст неправильный результат. И ищи потом концы...

Здравствуйте, vmpire, Вы писали:

V>Здравствуйте, Serginio1, Вы писали:

A>>> То, что null — это ошибка, очевидно.
A>>>А почему? Или при запуске программы нужно создать все (даже в данный момент не нужные) объекты, которые потом присвоить всем ссылкам в программе? И сколько это будет запускаться и сколько памяти сожрет?
S>> Можно для каждого класcа, по аналогии со String создавать пустой Empty
V>Тогда, если забыть проинициализировать, программа вместно честного падения будет продолжать работать и где-то совсем не там выдаст неправильный результат. И ищи потом концы...
Ну ты же работаешь со String.Empty. Можешь проверить на String.Empty, а можешь сразу применить IndexOf. На String.Empty исключения не будет.

Здравствуйте, Serginio1, Вы писали:

S> Ну ты же работаешь со String.Empty. Можешь проверить на String.Empty, а можешь сразу применить IndexOf. На String.Empty исключения не будет.

И в итоге ошибка "забыли заполнить поле" молча проходит тесты и выстреливает в продакшне. Прелестно.

На эти грабли уже наступили в VB. Закончилось тройкой из Null / Empty / Nothing. Если понравилось, можно проголосовать за вот тут.

Здравствуйте, Serginio1, Вы писали:

A>>>> То, что null — это ошибка, очевидно.
A>>>>А почему? Или при запуске программы нужно создать все (даже в данный момент не нужные) объекты, которые потом присвоить всем ссылкам в программе? И сколько это будет запускаться и сколько памяти сожрет?
S>>> Можно для каждого класcа, по аналогии со String создавать пустой Empty
V>>Тогда, если забыть проинициализировать, программа вместно честного падения будет продолжать работать и где-то совсем не там выдаст неправильный результат. И ищи потом концы...
S> Ну ты же работаешь со String.Empty. Можешь проверить на String.Empty, а можешь сразу применить IndexOf. На String.Empty исключения не будет.
В том то и проблема.
Если nullable тип не проинициализирован, а проверки нет — всё упадёт достаточно быстро и будет легко найти причину.
Если не-nullable тип не проинициализирован, а проверки нет — всё моет и вообще не упасть а вылезет вообще не там.
Ну а если для не-nullable типов везде нужно ставить проверки (которые автоматически есть для nullable), то в чём польза-то?

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:

S>> Ну ты же работаешь со String.Empty. Можешь проверить на String.Empty, а можешь сразу применить IndexOf. На String.Empty исключения не будет.

S>И в итоге ошибка "забыли заполнить поле" молча проходит тесты и выстреливает в продакшне. Прелестно.

Но при NotNull такого не будет.
S>На эти грабли уже наступили в VB. Закончилось тройкой из Null / Empty / Nothing. Если понравилось, можно проголосовать за вот тут.

Для иммутабельных типов NotNull считаю приемлен.

Здравствуйте, Kolesiki, Вы писали:

K>Очередная статья о C# 7 заставила задуматься: а в чём профит от non-null типов? То, что null — это ошибка, очевидно. Но разве можно не намокнуть, "запретив дождь"?!
K>Ведь null — это и есть индикатор, что что-то пошлó не так! Просто "взрыв на присвоении null" ничего не даст — нужно смотреть глубже в алгоритм и делать больше проверок/диагностик, чтобы null не вылезал, когда уже слишком поздно. Другими словами, non-null типы просто бесполезны!
K>Если вы поняли мою идею (или её ошибочность), отпишитесь — интересная тема.

Подобное есть в Котлине, при чем по умолчанию. Может поискать что они на это говорят?

https://kotlinlang.org/docs/reference/null-safety.html

Как на меня идея имеет будущее.

Здравствуйте, vmpire, Вы писали:

V>Здравствуйте, Serginio1, Вы писали:

A>>>>> То, что null — это ошибка, очевидно.
A>>>>>А почему? Или при запуске программы нужно создать все (даже в данный момент не нужные) объекты, которые потом присвоить всем ссылкам в программе? И сколько это будет запускаться и сколько памяти сожрет?
S>>>> Можно для каждого класcа, по аналогии со String создавать пустой Empty
V>>>Тогда, если забыть проинициализировать, программа вместно честного падения будет продолжать работать и где-то совсем не там выдаст неправильный результат. И ищи потом концы...
S>> Ну ты же работаешь со String.Empty. Можешь проверить на String.Empty, а можешь сразу применить IndexOf. На String.Empty исключения не будет.
V>В том то и проблема.
V>Если nullable тип не проинициализирован, а проверки нет — всё упадёт достаточно быстро и будет легко найти причину.

То, что я предложил касается иммутабельных типов. Для них можно заводить синглетоны. И в классе отрабатывать эти Empty

V>Если не-nullable тип не проинициализирован, а проверки нет — всё моет и вообще не упасть а вылезет вообще не там.
V>Ну а если для не-nullable типов везде нужно ставить проверки (которые автоматически есть для nullable), то в чём польза-то?

Не вижу разницы на сравнение между Null или Empty в качестве сравнения. А вот у Empty можно вызывать методы, свойства и тд которые по умолчанию.
Но опять это касается иммутабельных типов.

Здравствуйте, Serginio1, Вы писали:

S>>И в итоге ошибка "забыли заполнить поле" молча проходит тесты и выстреливает в продакшне. Прелестно.
S> Но при NotNull такого не будет.
Эмм, мы всё ещё про это говорим:

A>Или при запуске программы нужно создать все (даже в данный момент не нужные) объекты, которые потом присвоить всем ссылкам в программе? И сколько это будет запускаться и сколько памяти сожрет?
Можно для каждого класcа, по аналогии со String создавать пустой Empty

?
Ну вот оно конечно от null избавит, но лечение хуже болезни будет — отличить "забыли заполнить" от "пустое значение" теперь низзя.
Правильный вариант тут — явно помечать поле как "может быть null" и отдать остальное компилятору на откуп.

Здравствуйте, Serginio1, Вы писали:

S>>> Ну ты же работаешь со String.Empty. Можешь проверить на String.Empty, а можешь сразу применить IndexOf. На String.Empty исключения не будет.
V>>В том то и проблема.
V>>Если nullable тип не проинициализирован, а проверки нет — всё упадёт достаточно быстро и будет легко найти причину.

S> То, что я предложил касается иммутабельных типов. Для них можно заводить синглетоны. И в классе отрабатывать эти Empty
Ну так это ещё код который нужно написать и не забыть

V>>Если не-nullable тип не проинициализирован, а проверки нет — всё моет и вообще не упасть а вылезет вообще не там.
V>>Ну а если для не-nullable типов везде нужно ставить проверки (которые автоматически есть для nullable), то в чём польза-то?

S> Не вижу разницы на сравнение между Null или Empty в качестве сравнения. А вот у Empty можно вызывать методы, свойства и тд которые по умолчанию.
S>Но опять это касается иммутабельных типов.
Разница в том, что для nullable никаких проверок писать не надо, оно и так упадёт

Здравствуйте, Sinix, Вы писали:

S>Ну вот оно конечно от null избавит, но лечение хуже болезни будет — отличить "забыли заполнить" от "пустое значение" теперь низзя.

Правильный вариант — не давать использовать переменную, значение которой не было установлено хотя бы по одному пути управления.

Здравствуйте, hardcase, Вы писали:

H>Правильный вариант — не давать использовать переменную, значение которой не было установлено хотя бы по одному пути управления.

Не работает такой подход без кардинально ломающих изменений, получится два "недопустимых" значения — null и empty.
Breaking changes оставляем любителям, остаётся только один вариант: научить компилятор нормально работать с null и на этом перестать изобретать что-то ещё.

Здравствуйте, Sinix, Вы писали:

K>> а в чём профит от non-null типов?

S>Кэп: в api прописываешь, где конкретно ожидаешь null, компилятор предупреждает о возможном null

Увы, бестолковый пример к статье как раз и не иллюстрирует подобного профита. И насколько я понял, "улучшение" состоит ровно в обратном: указывать, где тип НЕ может быть null.
Ну ОК, возьмём гипотетический пример:

void CreateFile(string! name) {...}

CreateFile(OldFun());

И тут на ровном месте имеем проблему:
1. Если даже мы "интуитивно уверены", что null принципиально не может возвратиться из OldFun, никого это не спасёт — либо превращай non-null error в warning, либо уродуй код отключением предупреждений, либо выноси обращение к OldFun в отдельную переменную с проверкой, но в любом случае получаешь кодокаку.
2. Допустим, OldFun — чужая функция и нет возможности указать, что она всегда возвращает non-null. И это 100% 3-rd party библиотек. Значит введением non-null, мы сразу огребаем от всего легаси кода. А если этот non-null введут в сам дотнет?!
3. Null — он как бы и проблема, но где это критично, можно обойтись более строгим кодом с проверками. А где некритично, да и нехай вылазит NPE — сами и виноваты!

Я всё это к чему: к инверсии зависимостей Не должна функция, которая является сторонней к нашему коду, диктовать нам как её вызывать. Наоборот, мы контролируем, где и как мы хотим нарваться на грабли. Скажем, есть глубоко вложенные вызовы всякой фигни, но ловим проблемы только на верхнем уровне. А теперь представь, самый вложенный метод вдруг закочевряжится "хочу не нулл!". Что, курочить весь код ради Math.sqrt??

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

Ну и как итог, зачем курочить язык (и впоследствии чужой код), если можно сделать сторонний анализатор, который сделает более глубокие проверки (как у PVS Studio) за более длительное время, но зато даст более качественный результат?

Здравствуйте, Sinix, Вы писали:

S>Кэп: в api прописываешь, где конкретно ожидаешь null...

Да, и ещё один важный момент: искушение скидывать проверки на других. Тысячи библиотековаятелей с радостью нафигачат fun(Class! obj), лишь бы писать поменьше! Это превратит разработку в кошмар из проверок на пустом месте.
Конечно, можно и не обращать внимания на warnings, но какой тогда смысл их иметь?