The compiler doesn't add any null checks or other runtime constructs in a nullable context.
В публичном API по-прежнему нужно делать проверки на null.
По крайней мере Microsoft сам так делает и в гайдлайне советует. (Пруфлинк навскидку я найти не смог.)
Q>The compiler doesn't add any null checks or other runtime constructs in a nullable context.
Q>В публичном API по-прежнему нужно делать проверки на null.
Мало кто из нас делает публичный API.
Q>По крайней мере Microsoft сам так делает и в гайдлайне советует. (Пруфлинк навскидку я найти не смог.)
Логично. Ведь библиотеками microsoft могут пользоваться как те, кто использует nullable, так и те, кто не использует.
Re[2]: throw new ArgumentNullException - по прежнему пишите в 2021?
Здравствуйте, yenik, Вы писали:
Y>Сделали бы они уже атрибут какой-нибудь для null и других проверок.
В C# 10 планировали добавить !! к аргументу для вставки null-проверки с броском ArgumentNullException. Но я сейчас посмотрел в «What's new in C# 10.0» [1] и не нашёл там этого пункта.
S>>>По прежнему все аргументы функции проверяете на null вручную или что-то уже придумали за 20 лет? G>>https://docs.microsoft.com/en-us/dotnet/csharp/nullable-references
S>А разве это избавляет от проверки аргументов на null? Все равно приходится писать, т.к. внешний пользователь может предать null.
Дурь какая-то. В int же нельзя null передать. Надо чтобы и в string нельзя было. Бросать InvalidCastException. А то зачем называть типы non-nullable.
Y>>Сделали бы они уже атрибут какой-нибудь для null и других проверок.
Q>В C# 10 планировали добавить !! к аргументу для вставки null-проверки с броском ArgumentNullException. Но я сейчас посмотрел в «What's new in C# 10.0» [1] и не нашёл там этого пункта.
Вот я и говорю — атрибут, а не это чудо-юдо. Такой, чтобы вызывался для проверки значения параметра.
Лучше сделать абстрактный и парочку популярных реализаций.
Здравствуйте, yenik, Вы писали:
Y>Надо чтобы и в string нельзя было... А то зачем называть типы non-nullable.
В C# присобачивали эти nullable annotations, сохраняя совместимость со старыми версиями языка.
В Kotlin тоже, но там нужна была только совместимость с Java и JVM, не со старыми версиями языка.
Y>>Надо чтобы и в string нельзя было... А то зачем называть типы non-nullable.
Q>В C# присобачивали эти nullable annotations, сохраняя совместимость со старыми версиями языка.
Да это понятно, решили рубить хвост по частям. Получилось не супер.
Здравствуйте, yenik, Вы писали:
Y>Вот я и говорю — атрибут, а не это чудо-юдо.
Это не чудо-юдо, а вполне здравое решение. 90% всех проверок аргументов в публичном API — это проверки на null с бросанием ArgumentNullException без кастомного message. Вот для этого частого частного случая и нужен краткий синтаксис.
А для всего остального отлично работают традиционные проверки с явным бросанием исключений.
Y>Вот я и говорю — атрибут
У JetBrains вроде есть какие-то атрибуты с постпроцессингом сборки (автоматической вставкой if-throw в IL). Не знаю никого, кто бы их использовал.
Глаза у меня добрые, но рубашка — смирительная!
Re[3]: throw new ArgumentNullException - по прежнему пишите в 2021?
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>>>По прежнему все аргументы функции проверяете на null вручную или что-то уже придумали за 20 лет? G>>https://docs.microsoft.com/en-us/dotnet/csharp/nullable-references
S>А разве это избавляет от проверки аргументов на null? Все равно приходится писать, т.к. внешний пользователь может предать null.ъ
"Внешний пользователь" работает в одном сольшене с тобой, то можно и у него включить nullable references и он не сможет передать null.
Re[4]: throw new ArgumentNullException - по прежнему пишите в 2021?
Здравствуйте, yenik, Вы писали:
S>>>>По прежнему все аргументы функции проверяете на null вручную или что-то уже придумали за 20 лет? G>>>https://docs.microsoft.com/en-us/dotnet/csharp/nullable-references
S>>А разве это избавляет от проверки аргументов на null? Все равно приходится писать, т.к. внешний пользователь может предать null.
Y>Дурь какая-то. В int же нельзя null передать. Надо чтобы и в string нельзя было. Бросать InvalidCastException. А то зачем называть типы non-nullable.
Можно, для этого нужно использовать систему типов.
let toInt (arg: string option) =
arg |> Option.defaultValue "0" |> System.Convert.ToInt32;; // =>
val toInt : arg:string option -> int
Some"1" |> toInt;; // =>
val it : int = 1
None |> toInt;; // =>
val it : int = 0
Y>>Вот я и говорю — атрибут, а не это чудо-юдо.
Q>Это не чудо-юдо, а вполне здравое решение. 90% всех проверок аргументов в публичном API — это проверки на null с бросанием ArgumentNullException без кастомного message. Вот для этого частого частного случая и нужен краткий синтаксис.
По мне так чудо-юдо. Частый случай — ещё не повод добавлять не присущие языку синтаксические элементы. Этак можно return заменить на <, например.
Кстати, посмотрел сейчас AspNetCore, там без этих проверок вообще обходятся.
Скорее готов согласиться с http://rsdn.org/forum/dotnet/8055290.1
Здравствуйте, yenik, Вы писали:
Y>>>Вот я и говорю — атрибут, а не это чудо-юдо.
Q>>Это не чудо-юдо, а вполне здравое решение. 90% всех проверок аргументов в публичном API — это проверки на null с бросанием ArgumentNullException без кастомного message. Вот для этого частого частного случая и нужен краткий синтаксис.
Y>По мне так чудо-юдо. Частый случай — ещё не повод добавлять не присущие языку синтаксические элементы. Этак можно return заменить на <, например.
Уже присущие
string someString = otherString!;
что означает, переменная otherString не null — мамой клянусь!
