NullableAttribute and C# 8 | Jon Skeet's coding blog https://codeblog.jonskeet.uk/2019/02/10/nullableattribute-and-c-8/

так точно не забудешь

так точно не забудешь

А в чём проблема? Вроде всё понятно.

Причем не совсем ясны резоны

Плюс еще есть хреновые практики возврата null, если ничего не найдено

Василий, есть папиры с прямым доказательством беды этой практики? Устал уже просить не возвращать нулы

А разве это неочевидно?

Их не устраивает объяснение, что нулл ломает программный контракт и является элементом почти всех множеств

Василий, есть папиры с прямым доказательством беды этой практики? Устал уже просить не возвращать нулы

В теории, если нужно уйти от нулабельности и сохранить совместимость, имело бы смысл просто ввести compiler directives на принудительное включение

Ну папирами я не интересуюсь, возможно, что они в природе есть. Проблема в том, что с возвращенным результатом мы обычно что-то хотим сделать. В теории в c# проблема решается паттерном tryparse,find whatever, когда нам возвращается дополнительный признак, нашли мы что-то или нет. Не знаю, возвращается ли сейчас тапл или приходится через out параметры. Второй подход может заключаться в том, что на любой результат поиска мы возвращаем список, но тут тоже палка о двух концах, т.к. с одной стороны это убирает проблемы с возвратом null, с другой стороны приходится перестраивать мышление в случаях, когда возвращается только один результат. Третий подход - самописный Option/Result, но про такие вещи в проде лучше не заикаться, конечно.

Так здесь не в совместимости даже дело, а в том, чтобы можно было информацию о нуллябельности восстановить в рантайме. Например, для каких-нибудь библиотек, которые используют рефлексию. Эти аттрибуты именно для них в том числе и оставляются.

Трайкетч это признание своей беспомощности

Ну ты же понимаешь, как они будут использоваться в итоге?

Люди руками всё равно эти аттрибуты выставлять не будут. Это чисто выхплоп компилятора. Использоваться будут теми же json десериализаторами, например.

Ты очень хорошего мнения о людях

Люди ленивые черты и вряд ли будут руками такую хрень писать.

Ну папирами я не интересуюсь, возможно, что они в природе есть. Проблема в том, что с возвращенным результатом мы обычно что-то хотим сделать. В теории в c# проблема решается паттерном tryparse,find whatever, когда нам возвращается дополнительный признак, нашли мы что-то или нет. Не знаю, возвращается ли сейчас тапл или приходится через out параметры. Второй подход может заключаться в том, что на любой результат поиска мы возвращаем список, но тут тоже палка о двух концах, т.к. с одной стороны это убирает проблемы с возвратом null, с другой стороны приходится перестраивать мышление в случаях, когда возвращается только один результат. Третий подход - самописный Option/Result, но про такие вещи в проде лучше не заикаться, конечно.

Почему? Я вот на двух работах завёз резалт и брат не умер

Но очень медленно

Вопрос в том, кто их будет поддерживать, когда тебя не станет

Вопрос в том, кто их будет поддерживать, когда тебя не станет

Как насчёт выгнать бездельников из профессии?

Ибо было совсем как-то неприятно с версиями пакетов

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

Есть мнение, что typesafe код гораздо легче поддерживать и позволяет быстрее вводить фичи

Ты пока молод и наивен

Бизнесу на это похуй

На TTM?

А вот если бы работало, то все бы боялись трогать

Так потому и боятся, что не понятно как работает

И вот за данные бизнес трясется