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 — когда кто кого