Re: C# 8 и null-допустимость - ошибка на миллиард - .NET

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

S>>и а это у тебя по сути структура это аналог decimal
S>>и передаешь ты не obj, а указатель на структуру.
S>>Все твои методы по сути принмают ссылку на Структуру.

K>Там чёрным по белому написано class, значит у меня класс, а не структура, тем более, что в плюсах структура — то же самое, что и класс.

На заборе тоже написано. В чем разница в С++ между классом и структурой?

S>> Аналог в шарпе все тоже как и у тебя
S>>void foo(ref A d)
S>>{
S>>}

S>>A[] b= new A[1];
S>>foo(ref b[0])

K>с оговоркой на то, в реальной жизни этим пользоваться нельзя для обозначенных мною целей.
K>Если А — класс, то поведение совсем другое и проверки на null никуда не уходят, а на структурах без наследования далеко не уедешь.

Еще раз классы в C# и С++ разные понятия. Классы С++ по сути C# структуры. Размещаются на стеке и в куче

S>> Просто классы в С++ и структуры суть одного и того же. В C# это другое.
S>>Структуры боксятся , сборщик мусора отрабатывает по разному (2 копии получается)

S>>Но твои

S>>void foo2(A& a)

S>>это аналог

S>>void foo2(ref int a)

S>>Так как A это структура!!
S>>А аналог C# это A*

K>т.е. когда A *a = new A(); // это создание объекта класса
K>A &b = *a; // это уже структура, хотя и область памяти и тип данных тот же?)

Да это аналог С#
ref A b= ref a;

S>> В C# ввели ссылочных локальных переменных.
S>> То есть можно получить ссылку на структуру и работать с ней.
S>>Передавать в параметрах, возвращать из функций, привязываться к локальным переменным

S>>

S>>class Program
S>>    {
S>>        static int[] testArray = new int[] { 1, 2, 3 };
S>>        static void Test(ref int d)
S>>        {
S>>            d = 5;
S>>        }

S>>        static ref int Test( int d)
S>>        {
S>>            return ref testArray[d];
S>>        }

S>>        static void Main(string[] args)
S>>        {
S>>            Console.WriteLine("Hello World!");
S>>            int r = 4;

S>>            ref int d = ref r;
S>>            Test(ref d);

S>>            ref int d2 = ref Test(1);

S>>            Test(ref d2);

S>>            Console.WriteLine(testArray[1].ToString());
S>>        }
S>>    }
S>>

K>Это не аналог, т.к. тут нет класса, который был в примере на плюсах.
K>Я же говорю: мне параллельно на внутреннюю организацию и т.п. В плюсах создаёшь класс с наследованием и всем таким, дальше передаёшь ссылку на объект этого класса и её не нужно проверять на null во всех методах.
K>Пусть хоть компилятор внутри втихаря сам генерирует проверки на null, которые сейчас пишутся вручную, но в языке должна быть возможность работать с объектами, которые не могут быть null.

Еще раз классы С++ это аналог C# структуры. Только можно наследоваться и размещать в куче.
Но в С++ и нет сборщика мусора, боксинга итд. Нельзя сравнивать несравниваемое.

А ветка как ра о том, что ввели ссылочные типы которые не могут быть null. И за проверкой следит компилятор.

Заменяю structure A и все тоже что и на C++

Но на самом деле в будущем может и сделают классы которые будут размещаться на стеке.
https://xoofx.com/blog/2015/10/08/stackalloc-for-class-with-roslyn-and-coreclr/

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

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

S>>>и а это у тебя по сути структура это аналог decimal
S>>>и передаешь ты не obj, а указатель на структуру.
S>>>Все твои методы по сути принмают ссылку на Структуру.

K>>Там чёрным по белому написано class, значит у меня класс, а не структура, тем более, что в плюсах структура — то же самое, что и класс.

S>На заборе тоже написано. В чем разница в С++ между классом и структурой?

тем, что структуры = класс с публичными по умолчанию методами и полями. Наследование есть? Значит класс

S>>> Аналог в шарпе все тоже как и у тебя
S>>>void foo(ref A d)
S>>>{
S>>>}

S>>>A[] b= new A[1];
S>>>foo(ref b[0])

K>>с оговоркой на то, в реальной жизни этим пользоваться нельзя для обозначенных мною целей.
K>>Если А — класс, то поведение совсем другое и проверки на null никуда не уходят, а на структурах без наследования далеко не уедешь.

S> Еще раз классы в C# и С++ разные понятия. Классы С++ по сути C# структуры. Размещаются на стеке и в куче

Это какие-то самостоятельно выдуманные определения классов и структур?

S>>> Просто классы в С++ и структуры суть одного и того же. В C# это другое.
S>>>Структуры боксятся , сборщик мусора отрабатывает по разному (2 копии получается)

S>>>Но твои

S>>>void foo2(A& a)

S>>>это аналог

S>>>void foo2(ref int a)

S>>>Так как A это структура!!
S>>>А аналог C# это A*

K>>т.е. когда A *a = new A(); // это создание объекта класса
K>>A &b = *a; // это уже структура, хотя и область памяти и тип данных тот же?)

S>Да это аналог С#
S>ref A b= ref a;

т.е. одна и та же область памяти и класс и структура одновременно?

S>>> В C# ввели ссылочных локальных переменных.
S>>> То есть можно получить ссылку на структуру и работать с ней.
S>>>Передавать в параметрах, возвращать из функций, привязываться к локальным переменным

S>>>

S>>>class Program
S>>>    {
S>>>        static int[] testArray = new int[] { 1, 2, 3 };
S>>>        static void Test(ref int d)
S>>>        {
S>>>            d = 5;
S>>>        }

S>>>        static ref int Test( int d)
S>>>        {
S>>>            return ref testArray[d];
S>>>        }

S>>>        static void Main(string[] args)
S>>>        {
S>>>            Console.WriteLine("Hello World!");
S>>>            int r = 4;

S>>>            ref int d = ref r;
S>>>            Test(ref d);

S>>>            ref int d2 = ref Test(1);

S>>>            Test(ref d2);

S>>>            Console.WriteLine(testArray[1].ToString());
S>>>        }
S>>>    }
S>>>

K>>Это не аналог, т.к. тут нет класса, который был в примере на плюсах.
K>>Я же говорю: мне параллельно на внутреннюю организацию и т.п. В плюсах создаёшь класс с наследованием и всем таким, дальше передаёшь ссылку на объект этого класса и её не нужно проверять на null во всех методах.
K>>Пусть хоть компилятор внутри втихаря сам генерирует проверки на null, которые сейчас пишутся вручную, но в языке должна быть возможность работать с объектами, которые не могут быть null.

S>Еще раз классы С++ это аналог C# структуры. Только можно наследоваться и размещать в куче.

Напоминает бабушку, которая была бы дедушкой, если бы...

S>Но в С++ и нет сборщика мусора, боксинга итд. Нельзя сравнивать несравниваемое.

S>А ветка как ра о том, что ввели ссылочные типы которые не могут быть null. И за проверкой следит компилятор.

S>Заменяю structure A и все тоже что и на C++

S>Но на самом деле в будущем может и сделают классы которые будут размещаться на стеке.
S>https://xoofx.com/blog/2015/10/08/stackalloc-for-class-with-roslyn-and-coreclr/

Я просто привёл пример синтаксиса, который есть в другом языке и успешно используется.
Причём тут стек, структуры, сборщики мусора и всё прочее?
В плюсах нужные notnull объекты давным давно есть в виде ссылок. В шарпе вот только только родили аналог.
Только оказывается его нельзя было сделать, потому что в шарпе классы — это классы, а не структуры

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

K>>>В методе g я так же постараюсь добавить проверку на null, если он не поддерживает такие входные данные.
K>·>Ключевое слово выделил. Да, все стараются писать безбажный код, но иногда что-то идёт не так. Проблема сабжа в том, что очень легко сделать так, чтобы старался компилятор, а не разработчик. Но везде напихали null — без какой либо явной необходимости, просто традиционно.
K>Поэтому я и говорю о том, что ссылочные типы так же должны уметь быть не nullable как какой-нибудь int

Ну и сабж об этом.

K>>>В итоге две проверки одного и того же будет.
K>·>И вполне может просесть производительность на пустом месте.
K>и лишняя писанина добивает. IDE конечно позволяет автоматом сгенерировать проверки, но это тоже нужно поддерживать.
И на test coverage report без слёз смотреть нельзя будет. Сабж.

K>>>Если бы в f изначально пришла ссылка, то не потребовалось бы ни одной проверки на null в этих методах.
K>·>Зато потребовалось бы везде где есть вызовы этого f с разыменованием. Плюс помимо аргументов есть локальные переменные, поля классов, везде эта проблема.
K>где требуется разыменование, там мой метод, с которым я сейчас работаю, а не год назад. Здесь и сейчас я знаю нужно ли проверить указатель на null или нет.
_Ты_ знаешь. Но можешь легко забыть, компилятор тебе не поможет.

K>без notnull же мне придётся сначала посмотреть на описание метода или начало его тела, чтобы понять — можно туда null передать или же требуется так же в моём методе подавить точно такую же проверку, как перед разыменованием.
Хуже того. Ты можешь посмотреть сейчас, а потом, когда кто-нибудь где-нибудь что-нибудь как-нибудь поменяет — всё внезапно поломается, а компилятор даже не пискнет.

K>·>Потому что код иногда меняют, притом не только ты со своим "постараюсь", но и менее старательные разработчики. В реальном проекте через год эти 3 строчки превратятся в 300, что-то отрефакторится, выделится в отдельные методы, методы зареюзаются и в итоге твоё "точно знал" превратиться в "эээ... ну наверное... я надеюсь...".
K>без разыименования я получил бы ровно такую же ошибку в Runtime, только уже в методе, который бы получил нежданный null.
Притом это в c# ошибка, в плюсах просто UB — код может и не падать, а давать какие-то невменяемые результаты в каких-то совершенно неожиданных местах.

K>>>Зачем проверять на null указатель, который в начале метода инициализируется?

K>·>Верно, этим должен заниматься компилятор. Если бы компилятор это проверял, то некорректный код бы просто не скомпилился.
K>>>Если метод ожидает на вход не null-ссылку, то я должен проверить свои данные, а не разбираться в том, что умеет данный метод.
K>·>С какого перепугу "должен"? Скорее "должен постараться не забыть".
K>должен — значит моя обязанность только в том, чтобы преобразовать свои данные в подходящие для метода типы. В сам метод лазить не обязательно.
А лучше если это будет обязанность компилятора. То что в метод принимающий Date нельзя передать String — это компилятор проверит, а вот null внезапно приходится разбирать разработчику.

K>>>Если метод принимает указатель, то не понятно сразу — можно в него null передать или же нужно сначала в своём коде добавить проверку и не вызывать этот метод, чтобы дальше проверка на null не вывалила NRE.
K>·>А если это не метод, а коллекция указателей? Они могут быть null или нет?
K>В Runtime будет понятно

Тогда уж надо на JavaScript переходить.

K>>>>>Меня всегда удивляло почему сразу в шарпе ничего похожего не сделали и заставили везде эти проверки на null писать

K>>>·>Потому что это проблему не решает, скорее усугубляет.
K>>>Я вижу только проблемы в коде, который десереализует не nullable свойства, которые никак не проверяются нигде и дальше некие default(T) не уходят бесконтрольно по коду, вызывая странный эффект.
K>>>Для этого достаточно десереализуемые свойства объявлять nullable и работать как раньше или настраивать сериализаторы (проставлять Required и т.п.).
K>·>Проблема в том, что ты не можешь выразить в _языке_ понятие not-null или nullable в системе типов. ref проблему не решает, т.к. проверок компилятором оно не добавляет, просто соглашение, которое никак формально не проверяется, кроме как "поглядел глазами, вроде всё ок". А усугубляет т.к. теперь у нас появилось понятие битых ссылок и ещё больше UB.

K>сейчас со всякими int нет UB, а если по аналогии default(class) возвращать не null, а вызывать конструктор и создавать объект, то всё сломается?
Тут проблема немного в другом. Если тебя не устраивает то что int==0 по умолчанию и ты хочешь, чтобы в какой-то части программы число было без нулей, то ты можешь завести новый тип NonZeroInt, инкапсулирующий int с нужным поведением и использовать его повсюду безопасно, с контролем компилятора. В случае null это просто невозможно.

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

S>Пишут что сглупили, теперь хотят все исправить. Ваше мнение?

Кто именно сглупил и что исправляют??

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

S>>А ветка как ра о том, что ввели ссылочные типы которые не могут быть null. И за проверкой следит компилятор.

S>>Заменяю structure A и все тоже что и на C++

S>>Но на самом деле в будущем может и сделают классы которые будут размещаться на стеке.
S>>https://xoofx.com/blog/2015/10/08/stackalloc-for-class-with-roslyn-and-coreclr/

K>Я просто привёл пример синтаксиса, который есть в другом языке и успешно используется.
K>Причём тут стек, структуры, сборщики мусора и всё прочее?
Что касается классов в С++ и C# это разные вещи. В одном есть сборка мусора в другом нет.
Интерфейсы реализуются по другому итд.

Что бы работать объектом класса как со структурой нужно добавлять информацию для сборщика мусора.
Объекты класса не размещаются на стеке итд. Разная архитектура.

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

В твоем примере так или иначе нужнапроверка на null.
В шапрпе с вводом NotNull классов это не нужно.

У меня коллега сейчас пишет на С и C#. И просто радуется как ребенок когда переходит на C#
Говорит какой же это детский язык!!

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

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

S>>>А ветка как ра о том, что ввели ссылочные типы которые не могут быть null. И за проверкой следит компилятор.

S>>>Заменяю structure A и все тоже что и на C++

S>>>Но на самом деле в будущем может и сделают классы которые будут размещаться на стеке.
S>>>https://xoofx.com/blog/2015/10/08/stackalloc-for-class-with-roslyn-and-coreclr/

K>>Я просто привёл пример синтаксиса, который есть в другом языке и успешно используется.
K>>Причём тут стек, структуры, сборщики мусора и всё прочее?
S>Что касается классов в С++ и C# это разные вещи. В одном есть сборка мусора в другом нет.
S>Интерфейсы реализуются по другому итд.

S> Что бы работать объектом класса как со структурой нужно добавлять информацию для сборщика мусора.
S>Объекты класса не размещаются на стеке итд. Разная архитектура.

Когда захотели, они добавили сахар в виде int? и т.п. Nullable<T>
Кто им мешал сделать человеческий синтаксис, а потом при компиляции уже генерировать нужные NRE и т.п., чтобы люди вручную это не писали?

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

S>В твоем примере так или иначе нужнапроверка на null.
S>В шапрпе с вводом NotNull классов это не нужно.

И как же в шарпе будет кастоваться без такой проверки Null класс в его NotNull аналог?
Эта проверка собственно и сейчас есть при конвертации int? в int

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

S>>В твоем примере так или иначе нужнапроверка на null.
S>>В шапрпе с вводом NotNull классов это не нужно.

K>И как же в шарпе будет кастоваться без такой проверки Null класс в его NotNull аналог?
K>Эта проверка собственно и сейчас есть при конвертации int? в int

Если нужно кастоваться разумеется проверка на null. Но на то он и каст.
Ну разумеется если ты работаешь с нуллабля типами тебе приходится проверять. Но большинство работает с int и не работают с int?

Тоже самое и с С++ если ты работаешь с *A. Тебе нужно сделать проверку на null.
Другое дело, что сишники привыкли работать не с кучей, а со стеком. Структура не может быть null

Нужно просто технику программирования поменять
https://docs.microsoft.com/ru-ru/dotnet/csharp/nullable-references
https://docs.microsoft.com/ru-ru/dotnet/csharp/nullable-migration-strategies

https://docs.microsoft.com/en-us/archive/msdn-magazine/2018/february/essential-net-csharp-8-0-and-nullable-reference-types
то есть будет тоже самое

static string? GetNullableString()

static void Тест1(string s)
{
// проверка на null не нужна
Тест2(s);
}

static void Тест2(string s)
{
// проверка на null не нужна
}


var s=GetNullableString();

 if (s==null)
   вызовем исключение 


Тест1(s!);

Найди различия с твоим примером

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

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

В отличие от C#, ссылки в C++ НЕ могут быть неинициализированными.
Что же касается указателей (пришедших из Си) — то их проверка на NULL является вполне себе нормальной практикой в C++.

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

V>Я считаю, что самая большая ошибка в борьбе с NRE — это борьба с NRE.
Смотря как бороться. Если игнорить проблему, да, косяк. Но современный способ решения проблемы — если ссылка указывает на Object, то она гарантирована не может иметь null значение никогда физически. Если null допустим, то тип будет Object|Null или же Object?. И уже на этапе компиляции будет невозможно присвоить null. И далее, если у объекта Object? сделали проверку на null, в той ветке, где объект не null его тип становится Object и он уже взорваться дальше гарантированно не может.

Соответственно все очень неплохо получается и надежно, а также компактно. Говорю как тот, кто использует языки с подобным поведением уже больше 5 лет.

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

S>Найди различия с твоим примером

Так я про это и писал изначально.
Плюсы были просто как пример того, что тема рабочая

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

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

S>>Найди различия с твоим примером

K>Так я про это и писал изначально.
K>Плюсы были просто как пример того, что тема рабочая

Еще раз твой пример со структурами , мой пример с классами! Нет никакого приведения к структуре.
Как ты будешь работать со строками, массивами, массивами указателей? Твой подход не спасает от проверки на null.

Со структурами тоже ввели переменные ссылки, которые полностью соответствуют твоему примеру. Так, что вашему С++ еще догонять и догонять.

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

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

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

S>>>Найди различия с твоим примером

K>>Так я про это и писал изначально.
K>>Плюсы были просто как пример того, что тема рабочая

S> Еще раз твой пример со структурами , мой пример с классами! Нет никакого приведения к структуре.
S>Как ты будешь работать со строками, массивами, массивами указателей? Твой подход не спасает от проверки на null.

S>Со структурами тоже ввели переменные ссылки, которые полностью соответствуют твоему примеру. Так, что вашему С++ еще догонять и догонять.

Не надоело еще выдумывать свои классификации и определения?
В шарп ввели возможность делать ссылочные типы NotNull на уровне компилятора.
Это круто и замечательно, жаль, что изначально этого не было. Всё.

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

K>В шарп ввели возможность делать ссылочные типы NotNull на уровне компилятора.
K>Это круто и замечательно, жаль, что изначально этого не было. Всё.

Вот а ветка то как раз о том, null-допустимость — ошибка на миллиард.
Рад, что ты согласился, что это не ошибка, а преимущество.

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

S>https://m.habr.com/ru/company/piter/blog/501520/

S>Пишут что сглупили, теперь хотят все исправить. Ваше мнение?

Сглупили не они а Хоар и оттуда null прополз в основные мейнстримовые языки т.к.
авторы их побоялись изначально задать явную невозможность присваивания NULL потому что не хотели что бы девелоперы переучивались
(ну почему блин почти все создатели языков так этого боятся)

Так что они исправляют заимствованный косяк идущий имхо аж с алгола

Время покажет насколько удобно это будет... сейчас очень рано говорить

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

V>>Я считаю, что самая большая ошибка в борьбе с NRE — это борьба с NRE.
E>Смотря как бороться. Если игнорить проблему, да, косяк.
Так проблемы-то нет. Точнее, есть, но другая, более общая.
Если переменную не проинициализировали, а стали использовать, то это ошибка, независимо от того, какой это тип. ReferenceType тут ничем не особенный.
Если, например, это int, который должен быть проинициализирован, но там 0, и это приводит к неправильному поведению программы, это то же самое, что непроинициализированная строка, которая приводит к неправильному поведению.
Сейчас с ReferenceType даже лучше, потому, что программа падает, вместо того, чтобы выдавать втихую неверный результат.

E>Но современный способ решения проблемы — если ссылка указывает на Object, то она гарантирована не может иметь null значение никогда физически. Если null допустим, то тип будет Object|Null или же Object?. И уже на этапе компиляции будет невозможно присвоить null. И далее, если у объекта Object? сделали проверку на null, в той ветке, где объект не null его тип становится Object и он уже взорваться дальше гарантированно не может.
Да, часть потенциальных ошибок проверка компилятором покроет. Но никто не мешал сделать ту же самую проверку по атрибуту [NotNull], и ЕМНИП, какие-то средства статического анализа так уже и делали.
И это, конечно, хорошо, как и всякое выявление ошибок при статическом анализе. Но для этого не обязательно было менять язык.
Но, в силу обстоятельств, про которые я уже написал, есть у меня основания считать, что вреда от этой фичи будет не меньше, чем пользы.

E>Соответственно все очень неплохо получается и надежно, а также компактно. Говорю как тот, кто использует языки с подобным поведением уже больше 5 лет.
В том то и дело, что в языках, где эта возможность есть изначально, проблемы не будет.
А в С#, где уже есть немалая база кода и куча программистов, которые привыкли уже к существующему поведению, проблемы будут.

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

E>>Соответственно все очень неплохо получается и надежно, а также компактно. Говорю как тот, кто использует языки с подобным поведением уже больше 5 лет.
V>В том то и дело, что в языках, где эта возможность есть изначально, проблемы не будет.
V>А в С#, где уже есть немалая база кода и куча программистов, которые привыкли уже к существующему поведению, проблемы будут.

Ну любые нововведения не сразу используются. Можно начинать с новых проектах, классов.

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

V>Если переменную не проинициализировали, а стали использовать, то это ошибка, независимо от того, какой это тип. ReferenceType тут ничем не особенный.
Во вех взрослых языках уже даво есть zero-init. Так что "неинициализированных переменных" в понимании низкоуровневых языков не былвает.
Более того компиятор C# с самого начала ругается на то, что ты обащается к переменной ссылочного типа, котрой не было присвоено значение.

V>Сейчас с ReferenceType даже лучше, потому, что программа падает, вместо того, чтобы выдавать втихую неверный результат.
Проблема не в локальных переменных, а в параметрах и возвращаемых значениях.
Функции часто возвращают null, а программисты часто принимают null в качестве параметра и не проверяют.
Поэтому nre просиходит зачастую не там где ошибка, а гораздо ниже по стеку вызовов или вообще в другой части кода.

V>Да, часть потенциальных ошибок проверка компилятором покроет. Но никто не мешал сделать ту же самую проверку по атрибуту [NotNull], и ЕМНИП, какие-то средства статического анализа так уже и делали.
Я тебе даже бльше скажу, новая фича и есть атрибут notnull, только работает немного не так. Ты должен явно указать где может быть null. На уровне .NET типов разницы нет.

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

V>А в С#, где уже есть немалая база кода и куча программистов, которые привыкли уже к существующему поведению, проблемы будут.
Для них фича необязательная.

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

V>>Если переменную не проинициализировали, а стали использовать, то это ошибка, независимо от того, какой это тип. ReferenceType тут ничем не особенный.
G>Во вех взрослых языках уже даво есть zero-init.
C/C++ — довольно взрослые языки

G>Так что "неинициализированных переменных" в понимании низкоуровневых языков не былвает.
G>Более того компиятор C# с самого начала ругается на то, что ты обащается к переменной ссылочного типа, котрой не было присвоено значение.
Возможно, я некорректно выразился, хотя, КМК было понятно по контексту. Имелась в виду не любая инициализация, а инициализация тем, что нужно по смыслу программы.
Потому, что с точки зрения zero-init и ReferenceTypes тоже уже проинициализированы.

V>>Сейчас с ReferenceType даже лучше, потому, что программа падает, вместо того, чтобы выдавать втихую неверный результат.
G>Проблема не в локальных переменных, а в параметрах и возвращаемых значениях.
G>Функции часто возвращают null, а программисты часто принимают null в качестве параметра и не проверяют.
G>Поэтому nre просиходит зачастую не там где ошибка, а гораздо ниже по стеку вызовов или вообще в другой части кода.
Спрасибо, конечно, но я как раз про это и говорил

V>>Да, часть потенциальных ошибок проверка компилятором покроет. Но никто не мешал сделать ту же самую проверку по атрибуту [NotNull], и ЕМНИП, какие-то средства статического анализа так уже и делали.
G>Я тебе даже бльше скажу, новая фича и есть атрибут notnull, только работает немного не так. Ты должен явно указать где может быть null. На уровне .NET типов разницы нет.
Я в курсе, спасибо.

V>>И это, конечно, хорошо, как и всякое выявление ошибок при статическом анализе. Но для этого не обязательно было менять язык.
V>>Но, в силу обстоятельств, про которые я уже написал, есть у меня основания считать, что вреда от этой фичи будет не меньше, чем пользы.
G>Только ты эти основания не написал
тут

V>>А в С#, где уже есть немалая база кода и куча программистов, которые привыкли уже к существующему поведению, проблемы будут.
G>Для них фича необязательная.
Так для них как раз эта проблема и существует. Для "илиты", у которых 20 лет опыта, которые пишут программы с нуля, без жёстких временных ограничений, с кучей тестов и на всех новых технологиях проблемы NRE, собственно, и нет.

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

S>Пишут что сглупили, теперь хотят все исправить. Ваше мнение?

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

default(int?) = null
default(string?) = null
default(int) = 0
default(string) = ?

Из-за этого, компилятор не знает чем инициализировать значения ненулевых ссылочных типов, т.к. в системе типов нет такого понятия. И пока компилятор не научится понимять что

default(string?) = null
default(string) = string.Empty

вы не сможете это фичу использовать как следует нигде, кроме интерфейсных контрактов.

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

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

S>>Пишут что сглупили, теперь хотят все исправить. Ваше мнение?

A>Исправление не получилось, так как оно использует кривую алгебру под капотом. В ней недостает понятия пустого значения ссылочного типа. Приведу пример:

A>

A>default(int?) = null
A>default(string?) = null
A>default(int) = 0
A>default(string) = ?
A>

A>Из-за этого, компилятор не знает чем инициализировать значения ненулевых ссылочных типов, т.к. в системе типов нет такого понятия. И пока компилятор не научится понимять что

https://docs.microsoft.com/en-us/dotnet/csharp/nullable-migration-strategies#late-initialized-properties-data-transfer-objects-and-nullability

Initialize the property to null

As a terser alternative to using a nullable backing field, or if the library that instantiates your class is not compatible with that approach, you can simply initialize the property to null directly, with the help of the null-forgiving operator (!):

[Required]
public string FirstName { get; set; } = null!;

[Required]
public string LastName { get; set; } = null!;

public string? VehicleRegistration { get; set; }

You will never observe an actual null value at runtime except as a result of a programming bug, by accessing the property before it has been properly initialized.

В конструкторах ты должен их заполнять.

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	14.05.20 12:46
Оценка:

	От:	karbofos42
	Дата:	14.05.20 13:08
	Оценка:

	От:	·
	Дата:	14.05.20 13:21
	Оценка:

	От:	Kolesiki
	Дата:	14.05.20 14:01
	Оценка:	+1

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	14.05.20 14:53
Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	15.05.20 15:42
Оценка:

	От:	Aquilaware
	Дата:	16.05.20 14:57
	Оценка:	53 (1)