Комментарии 23
Меня, честно говоря, пугают последние изменения в шарпе. Вместо того, чтобы стимулировать людей писать код с большим количеством переменных, где в любом месте можно поставить breakpoint и легко его продебажить, зачем-то идут в сторону уменьшения количества кода.
А потом ты такой сидишь и смотришь на метод с expression body, который вызывает другой метод, которому в параметры передаётся результат ещё какого-то метода, да теперь ещё и у которого в параметры передаётся строка с интерполяцией, где теперь ещё и многострочное выражение. И во всём этом хаосе где-то случается exception, а ты даже не понимаешь, как его продебажить...
В начале казалось, что работают над читабельностью кода, но похоже что последние изменения чистый маркетинг. Чтоб потом можно было сказать, что поднять сервер можно в "две строчки" и пофиг, что в этих строчках будет сотня вызовов и десятки функций. Скоро введут иероглифы, чтоб одним символом вызвать какую то встроенную конструкцию...
По крайней мере в райдере можно несколько брейкпоинтов в одной строке ставить (на каждое выражение)
Хотите много кода - пишите на Java.
myMethod(string param1!!, string megaparam!!, string megaparam3!!, string megaparam4!!)
Выглядит и читается крайне плохо. Лучшего синтаксиса они похоже не нашли.
myMethod(string! param1, string! megaparam, string! megaparam3, string! megaparam4) Хотя когда то давно было предложение расширить синтаксис для code contracts вот так:
myMethod(string param1, string megaparam, string megaparam3, int megaparam4)
require param1 not null, megaparam not null, megaparam4 > 0
{
}Да в чем проблема-то была с [NonNull] string myParam? Все эти символы выглядят все хуже и хуже (привет оператору "летающая тарелка").
Кроме того есть ??. Почему его нельзя было расширить и сюда тоже? Почему нельзя вставить свое исключение после !!. Почему наконец именно два !! а не один и не три?
Выглядит плохо. Полезность под вопросом.
А в чем польза рантайм проверки на null при наличии возможности проверки перед компиляцией?
Может 2 потому что 1 уже занят?
https://endjin.com/blog/2022/02/csharp-11-preview-parameter-null-checking
Тут разъяснение почему это не может быть частью типа.
По хорошему это должно быть расширяемо.
А вообще неясно какую реальную проблему это решает.
Из примера разве что нельзя писать сегодня кратко f(a!! => a.b());
И проверки на null будут в начале метода как полагается до всей логики, а не как пишут некоторые:
this._a = a ?? throw new Exception();
this._b = b ?? throw new Exception();
Так чем отличается
string param1!!
[nonnull ]string param1!!
[nonnull ]string param1
[nonnull ]string? param1!!
[nonnull ]string? param1
string? param1!!
Забавно то, что в коде, с которым мне приходилось иметь дело, для string самая частая проверка это IsNullOrEmpty, а не просто на null и тут получается, что для string параметров все равно if писать придется.
А еще есть массивы, которые проверяют не только на null, но и на Length>0, а так же элементы массива на null + если массив строк, то и IsNullOrEmpty :)
"Проверка Parameter на null" — эта же вещь нужна только если <Nullable>disable</Nullable>, так ведь?
Эта штука нужна если вы пишете библиотеку с публичным API. Вы ведь не можете полагаться на то, что у пользователя вашей библиотеки будут выставлены нужные вам настройки компиляции!
Если библиотека написана на C# 11 с включёнными nullability, то публичное API будет сформировано с учётом этого, нет?
Если библиотека написана на C# 11 с включёнными nullability, то у вас нет никаких гарантий что использующая библиотеку программа будет написана на C# 11 со включёнными nullability.
Самоисполняющееся пророчество, очень удобно. Да и не вижу большой пользы от замены NullReferenceException на ArgumentException - аджайловые пацаны ничего не кэтчат, а параноики кэтчат всё. Вообще, эксепшены давно пока включить в сигнатуру метода, тогда бы было меньше всего проблем.
Польза тут в том, что NRE может вылететь в случайном месте кода, в то время как явная проверка на null вылетит строго на входе в функцию. Это позволит куда проще найти ошибку.
Самоисполняющееся пророчество, очень удобно.
Где именно вы видите пророчество, и в чём заключается его самоисполнение?
Вы утверждаете что автору библиотеки с nullability стоит переживать о том что её могут использовать без nullability => выглядит как минус новых версий C# для тех кто еще не перешел => снижает заинтересованность в переходе на них => снижает количество проектов на них => приводит к высокой вероятности того самого использования библиотеки из не nullability контекста
Честно говоря, я долго не мог понять проблему, пока не прочитал про nullable references.
Теперь кажется понял, но чтобы убедиться: если библиотека написана на C# 11 с включёнными nullability, а программа — без nullability, то при использовании библиотечного кода, если я положу null в notnull-тип, покажется предупреждение?
Поговорим о фичах в предварительной версии C# 11