Comments 8
У вас в таблице опечатка - record struct с позиционной записью можно создавать с помощью инициализатора объектов. Вообще конструкторы и инициализаторы объектов ортогональны друг другу в каком-то смысле -- если объект создался с помощью какого-то конструктора (а у record struct есть дефолтный конструктор), те его поля и set/init свойства, которые видны в данном контексте можно присвоить в инициализаторе. В том числе, можно сначал инициализировать свойство в конструкторе и тут же пере-присвоить значение в инициализаторе.
Вообще, огромные вопросы к шпаргалкам в конце. Особенно к выбору, что использовать, рекорды или обычные классы/структуры. Это слабо связано с тем, будет ли использоваться тип в качестве поля другого типа. Обычные структуры чаще всего используются для оптимизаций, где можно избавиться от лишних аллокаций в куче и ускорить операции (как пример, особая поддержка struct-энумераторов в foreach или при ручном вызове для массивов, спэнов, и т.д.), record struct теперь по всей видимости будут представлять value-type DTO с хэшем, равенством, и т.д. (все эти ваши Point2D, RGB цвета и т.д., для чего раньше приходилось руками писать весь обвес). record это теперь go-to решение для доменных моделек и прочих value-object из-за иммутабельность по умолчанию и простоты создания, а так же из-за наследования. Ну и class на все остальное, включая EF, которому плохо от иммутабельных рекордов.
И 16 байт тут тоже так себе лимит. В зависимости от функций вашего кода, предача readonly record struct по in ссылке или не-readonly по ref (в зависимости от целей) может быть гораздо эффективнее чем использование ссылочного типа.
Короче, наверное каждая шпаргалка подлежит обсуждению.
В статье столько огрехов, что я бы её отьсюда убрал, чтобы не вводить незнающих людей в заблуждение.
Навскидку:
1) Ни record ни record struct не являются какими-то новыми типами данных. Это просто синтаксические конструкции которые компилятор превращает в самые обычные классы и структуры просто с дополнительным автоматически сгенерированным функционалом который.
2) Entity Framework и JSON давным-давно отлично понимают конструкторы с параметрами.
3) Совершенно не упомянуты readonly struct и readonly record struct про которые здесь надо было, конечно, написать.
4) И самое главное. У всех кто делает мутабельные структуры надо на лбу большими буквами писать: "Структура ВСЕГДА должна быть иммутабельной". Потому что количество граблей на которые можно наступить при использовании изменяемых структур просто неисчислимо
Согласен с вышесказанным.
Со структурами в любом виде много граблей. `struct` - это по сути оптимизация и ничего больше. Поэтому стоит как следует подумать, не является ли она преждевременной в каждом конкретном случае.
С пунктом 4 абсолютно согласен. Как-то до недавнего времени не доводилось работать с проектами старше core 3.1. И со структурами знаком только по F#. Из-за этого в голове отложилось, что структуры всегда иммутабельны. А в C# вон оно как на самом деле
А есть где-то общий список граблей изменяемых структур? Для памяти, потому как struct в кровавом энтерпрайзе вещь нечастая.
Вот ведь развели зоопарк из типов..
Record vs struct — когда кто кого