1000 и 1 способ инициализации типов в C# 12.0

ИМХО primary constructor сделан исключительно ради облегчения труда программистов при работе с DI.

Замена простыни

public class SomeService
{
  private readonly Service1 service1;
  private readonly Service2 service2;
  ...  
  private readonly Service100500 service100500;

  public SomeService(Service1 service1, Service2 service2, ... Service100500 service100500)
  {
    this.service1 = service1;
    this.service2 = service2;
    ...
    this.service100500 = service100500
  }
}

на

public class SomeService(Service1 service1, Service2 service2, ... Service100500 service100500)
{
 
}

многого стоит.

Кстати IDE подчеркивает желтым, если аргументы, объявленные в конструкторе, дальше не используются.

Вот вроде бы такие синтаксические плюшки должны помогать удобством, но чаще всего просто становятся обузой. С вероятностью в 80% ты её использовать не будешь, а учить надо, ведь кто-нибудь да напишет так, а ты не знаешь. :\

Этот вектор развития стал моей причиной ухода с шарпов. А жаль. Я сдиел на них буквально с детства. Помню ещё фреймворк версии 1.1 и то, каким офигительным тогда казался второй фреймворк. Помню свой первый профессиональный проект, за который я получил первую в жизни зарплату, написанный на MS .NET Framework 2.0 и шарпах. Всё было на ASP.NET со всеми новейшими плюшками. Да, это работало только на Винде и только под IIS, но работало стабильно и круто.

Шарпы ещё тогда славились "многословностью", но она была намного менее многословной чем Ява. Но эта самая многословность отличала шарпы от других (сосбенно скриптовых) языков. Всё было чётко и понятно. У тебя не было двусмысленности. Тебе не надо было перепроверять, что значит знак =, или какого типа у тебя переменные.

Я с большим недоумением смотрел на конструкцию var. Я вообще не понимал, почему её ввели. Для объявлений типа int t = 3 она была достаточно смешной. Для более сложный кейсов, когда тебе надо было объявить Class.Subclass.SubSubClass t = new Class.Subclass.SubSubClass() intellisence отлично справлялся с работой.

Да, понятно, нам хотелось сделать так, чтобы LINQ работал попроще. Поэтому мы начали делать type inference и всё такое.

Самая жесть началась с 2015 года, когда Скотт Хансельман объявил о том, что ASP.NET перешёл в ОpenSource и стал доступен на гитхабе. Шарпы последовали за ним, как и вся платформа. После этого началась дикая каша с названием множества фреймворков и версий продукта. .NET, Core, Mono и все остальные начали беситься.

С этого же времени в шарпы начали добавлять функциональность все кому не лень, в попытках "облегчить" этот язык. Но проблема в том, что ему изначально не надо было быть "лёгким". Он был разработан для взрослых дядек, которые пишут проекты по 4 года, и для который написание hello world занимает 2 недели, чтобы пробиться через всю бюрократию. Но в этом и была прелесть языка, особенно после всех ужасов яваскрипта, где у вас есть var, let и const, и наличиствуют приколы типа == и ===, с добавлением возможностей типа console.log({} + []); console.log([] + []); console.log({} + {}); console.log({} - []); console.log([] - []); console.log({} - {});Кстати, не отказывайте себе в удовольствии, вставьте этот код в консоль вашего браузера, и попробуйте предугодать ответы, которые вы увидите на экране.

Зачем надо было тратить усилия, для того, чтобы позволить запускать код без int Main()? Ну да, мы получили что-то что ещё больше похоже на Node.js. Но смысл в этом был какой? Каждая IDE для шарпов всегда начинала с того, что создавала Program.cs с int main. Но нам же нужен синтаксический сахар. Мы будем убивать boilerplate.

В шарпах всё было разложено по ящичкам, ящички были разложены по полочкам и приварены к полочкам, полочки были вкручены в стены десятью болтами на 30, стена была железобетонной, толщиной в 10 метров, и установлена на фундаменте в 50 метров в глубину. Сейчас мы начали добавлять "синтаксический сахар" в шарпы. Очень умное название. Ложечка сахара делает кофе намного более вкусным. Две ложечки заставляют тебя задуматься о том, надо ли тебе это. Три - и кофе уже приторный. Мешок сахара - и ты понимаешь что из этой комнаты тебе выходить только вперёд ногами.

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

В своё время самым сложным вопросом на собеседовании в шарпах было "расскажи про разницу между public, private, internal, protected и т.п." Сейчас у тебя есть вообще чёрт знает что (как хорошо показано в статье). И всё это сделано для того, чтобы сомнительный паттер dependency injection смог работать. Хотя, жить можно было и без DI. Голанг отлично без него живёт. Зато всё прикручено к полу болтами. Конструкции не имеют неясных значений.

Программирование - это очень детерминированная деятельность. Тебе надо дать чёткие инструкции для процессора, чтобы получить ожидаемый результат. Сейчас инструкции становятся всё более и более размытыми. И самое главное - я не могу понять, почему это происходит.

Что самое интересное, в мире, где все пишут с ChatGPT на пару эта boilerplate вообще не имеет никакого значения. Если тебе влом писать CRUD для класса, настрочи один метод, и попроси бота написать остальное. При этом ты будешь ясно видеть, если бот написал фигню. И это не занимает много времени.

Как же хорошо, что в моем повседневном языке Scala разработчикам вот уже на протяжении многих лет удается сохранять язык стабильным без погони за новыми фичами.

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

Как говорится, воруй как художник? Думаю, что это не про Primary Constructors, потому что насколько плохо своровать фичу это надо было постараться.

Как по мне, то в статье неверно изложена причина появления первичных конструкторов (Primary Constructors) в C#
Первичные конструкторы в C# - это не про "своровать фичу" (то есть функцию, если по-русски) из совсем дуругого языка, а про естественное развитие C# в выбранном его создателями направлении.

Мой многолетний взгляд на нововведения в C# привел меня к мысли,что это за направление: это увеличение лаконичности языка. Многие добавленные конструкции, такие как var в описателях , new() (без указания типа), код верхнего уровня (не включаемый в методы), определение тел методов, геттеров и сеттеров как стрелочных функций - они бьют именно в эту точку: позволяют сэкономить нажатия на клавиши при написании кода с той же само функциональностью. А заодно - писать меньше строк текста, улучшая обозримость программы. Первичные конструкторы, как они реализованы в C# 12 тоже направлены именно на это, на увеличение лаконичности: они позволяют сэкономить на размере кода - и самого конструктора, и на описаниях внутренних полей, используемых в методах. Потому они и сделаны так, минималистично. И эту задачу они, в целом, выполняют. Для других же задач - типа создания альтернативного способа полноценного, с областями видимости и пр., описания полей объекта - они не предназначены.
Единственный неочевидный выбор, который был сделан при создании этого расширения - это делать ли эти скрыте поля, которые могут понадобиться методам, неизменяемыми. В целом, решение тут неоднозначное, потому что поля в языке C# могут использоваться и так, и так, поэтому надо выбирать. Решение же добавлять возможность выбора, полагаю, было отвергнуто именно из соображений лаконичности. Созадатели языка решили - не делать, вероятно - потому что в C# все эти неизменяемые поля - это более поздние нововведения, а традиционно поля были изменяемыми.

Хорошо ли, что C# развивается именно в направлении повышения лаконичности - вопрос дискуссионнный. Лично мне, например, (и, судя по комментариям - не только мне) это не нравится: я умею печать достаточно быстро, чтобы пальцы обгоняли мысли о том, что надо писать, а улучшение обозримости программы, которое могло бы способствовать облегчению понимания ее кода, по-моему, с лихвой компенсируется усложнением языка, которое облегчению понимания кода отнюдь не способствует.
Но я-то программист ненастоящий, т.е. без коммерческого опыта стильномодномолодежной разработки, а потому вполне допускаю, что в области разработки типовых решений для того же веба скорость набора текста вполне может являться ограничивающим фактором (такие мнения я от веб-программистов слышал). А как оно там на самом деле - это тот вопрос, который должен волновать создателей языка: простые разработчики не могут влиять на то, куда пойдет этот процесс.

Недавно спрашивал про primary constructors у Медса Торгенсена. Политика такая: они перешли на более частые и более гранулярный релизы. У них несколько вариантов дальнейшего развития primary constructors (и других фичей), но ни одна из реализаций не лишена изъянов. Они выпускают минимальную версию в прод и ждут фидбек. На основе фидбека решают какая из реализаций удовлетворяет большинсиво разработчиков. Так что и блоки инициализаторов и управление уровнями доступа или изменяемостью/неизменностью - все это может появиться в следующих версиях языка. С чего может реально пригореть и что может поменять много идиом C# - это ключевое слово extension, но с ним ясности нет пока.

Что-то вы как-то все напутали.

• В примере 1 у меня получается false, а не true, что я делаю не так? Ваше заявление, что если поле не используется, то оно не сохраняется, не верно.

• В примере 2 вы зачем-то смешали primary constructor и immutability, как это связано? Существуют readonly struct, но, вообще-то, никто не обещал, что вместе c primary constructors введут еще и возможность ограничения классов на изменение

• По уровням доступа - просто используейте обычные конструкторы, а не primary, всегда можно указать все явно. Primary constructor это синтаксический сахар, который не создан, чтобы покрывать все возможные кейсы полного синтаксиса.

• В примере 3 вообще непонятна претензия, init отдельно, primary constructor отдельно. Вы сделали декларацию класса с primary constructor вместе обязательным полем с object initializer и удивляетесь, почему компилятор не позволяет вам использовать только одно из двух, называя это почему-то багом.

В документации же явно написано: primary constructor создает поля, доступные внутри описания класса. Это синтаксический сахар, которые покрывает простые кейсы для сокращения количества кода.

Многое, что делали с языком после С#6-7 - это порча хорошего и стройного языка и превращение его в джаваскрипт. Жабаскрипт такой только по историческим причинам, а тут сознательно портят язык.

Для верхнеуровневых языков скорость разработки зависит не от количества синтаксического сахара или того, пишешь ты конструктор за 30 символов или за 40, а от простоты и наглядности кода, возможностей выражать понятия доменной модели в коде наиболее близким способом, не увеличения, а лимитирования способов сделать одно и то же, ограничения возможностей "писать, что попало" и структурирование всего кода в определённые рамки, близость к натуральным языкам ддя простоты понятия и оперирования...

Основной тех. долг, который несёт косты для бизнеса это ошибки в проектировании доменной модели, макаронный код, проблемы времени жизни объектов и т.п., а не лишняя строка для определения пропсы.

Соглашусь с автором - primary constructor'ы классов/структур это просто жуткий провал в архитектуре синтаксиса C#. Самое главное, что он противоречит аналогичному синтаксису record. До этого я считал самым неудачным дизайном именно record - т.к. они не совместимы с классами - т.к. их нельзя отнаследовать от класса - это же было фиаско - технически же там нет никаких ограничений - "позади" record стоит просто кодогенерация - можно было бы и просто аннотацией обойтись (почти как в Kotlin - там правда вместо аннотации ключевое слово - но это не принципиально - всё равно будет определён class и никаких ограничений на наследование и конструкторы не накладывается; в C# даже такое определение как "record class" - это всего-лишь банальный "record") - но record это всё-таки другая тема, а C# 12 primary constructor это куда больший провал. Но, в будущем его ещё можно попробовать исправить - всё-таки введя возможность вставлять модификаторы доступа (+ readonly) в параметры primary constructor'а - если есть - то создавать поле.

Кстати, у record тоже есть аналогимчный косяк с параметрами primary constructor

//Вариант 1
public record Test(int A) 
{ 
  public int A; 
}

//Вариант 2
public record Test(int A) 
{ 
  public int A { get; set; } 
}

//Вариант 3
public record Test(int A)
{
	public readonly int A = 0; //Без инициализатора нельзя
}

var t1 = new Test(10);
var t2 = new Test(222222);
var t3 = new Test(3);

Console.WriteLine(t1.Equals(t2)); //true
Console.WriteLine(t1.A); //0
Console.WriteLine(t2.A); //0
Console.WriteLine(t3.A); //0

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

Поэтому для record надо так же писать

//Вариант 1
public record Test(int A) 
{ 
  public int A = A; 
}

//Вариант 2
public record Test(int A) 
{ 
  public int A { get; set; } = A
}

//Вариант 3
public record Test(int A)
{
	public readonly int A = A;
}

var t1 = new Test(10);
var t2 = new Test(222222);
var t3 = new Test(3);

Console.WriteLine(t1.Equals(t2)); //false
Console.WriteLine(t1.A); //10
Console.WriteLine(t2.A); //222222
Console.WriteLine(t3.A); //3

Так что первичный конструктор классов не так уж сильно отличается от первичного конструктора записей - но всё же отличие есть (отсутствие автогенерируемый свойств) - и это очень существенно!

особенно когда можно писать так

public record class Test1(int A) { }
public class Test2(int A) { }

и иметь прям принципиально разную архитектуру хранения данных (а не только разные принципы её обслуживания)

ну и такая вещь как

public class Test(int A)
{
	public int A {get; set;} = A 
    
    //как и такая
    //public int A {get; set;} 
}
var t = new Test(A:1) {A = 2};
Console.WriteLine(t.A); //2

Мне кажется дикой - на мой взгляд тут нужно генерировать синтаксическую ошибку - прочем не будь это первичным конструктором (а обычным), то так тоже можно было делать - и ранее это никого не смущало - можно воспринимать как мутацию класса при его инициализации (и тут даже есть своя логия и польза от этого)

Кстати это работает аналогично

public record class Test (int A)
{
	public int A {get; set;}
}

var t1 = new Test(A:10){A = 1};
var t2 = new Test(A:222222){A = 1};

Console.WriteLine(t1.Equals(t2)); //true
Console.WriteLine(t1.A); //1
Console.WriteLine(t2.A); //1

Кстати, рефлексия в обоих случаях (record или class)

var mt = t1.GetType();
foreach (var f in mt.GetFields())
    Console.WriteLine($"field: {f.Name}");
foreach (var f in mt.GetProperties())
    Console.WriteLine($"property: {f.Name}"); //Вернёт только свойство A

Так что у record это тоже провал, хоть у чуть меньший. И до сих пор никак это не поправлено!

Поэтому я и решил создать свою версию компилятора для .NET на базе Roslyn - где всё как в Kotlin (ну кроме suspend функций - асинхронность как в C#)