потому что это очень удобно и оффлайн можно работать

на маке не хватает райдера у которого ланг сервер не зависает насмерть

всё же настаивают на своём

Ну с явными nullable-ref типами оно действительно превращается в option

Так какая разница?

Нулл не типизированный

Так что не превращается

это просто варнинги от компилера

А какие с этим могут быть проблемы? Главное же, чтоб переменные имели тип

Ну это проблема реализации, да. Идейно, я никакой разницы не вижу

То есть, я бы не стал городить опшнал поверх этих типов

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

Большая разница, нуллябельность не композируется толком и от неё не реально нормальным образом абстрагироваться.

Литерал null можно сунуть куда угодно

В плюсах из-за этого nullptr случился.

Литерал None тоже можно сунуть куда угодно

1. нельзя сделать option<option<T>> (легко получаемая ситуация при вычислениях внутри опшонов)
2. null не несет никакой информации о типе
3. в случае конкретно шарпа у тебя аж два типа нуллабельности, один другого хуже, друг с другом совместимы посредственно
4. везде, где они есть, подразумеваются как значение для дефолтной инициализации - привет опечатки и протекающие нуллы в ненуллабельную часть
5. лишний элемент языка просто потому что
можно было бы тогда, например, Result так же в язык вкорячить, или еще что-нибудь

Понятно, что у него есть тип, но все же