K
Size: a a a
2021 April 30
W
И не только сторы, но и Equals, GetHashCode, и with, и Deconstruct. А при чем тут nullable?
V
при том, что в конструкторах record'а будет проверяться nullability, а просто так в классе без конструктора оно всегда будет ругаться, что там будет null, хотя, если класс конструируется как new A { mystring = "aaa" } «— проверяться, сконструировался ли класс с null значением в не-nullable типах, должно здесь, а не в объявлении класса.
ИМХО
ИМХО
V
конструктора нет. Не поэтому ли во всём генерируемом коде от EF проставляется #nullable disable?
W
А init; get; не порешает твою проблему?
V
nullable warning'и его игнорируют
DP
Конструктор есть, просто заполнение через рефлекшн
DP
А так по дефолту там нуллы же
V
да, нуллы. Он они там появятся, только если позвать просто new X(); без явного присваивания после конструирования, типа new X() { Y = "text" }
Т.е. предупреждения про nullable лучше бы было показывать по месту создания X, а не в объявлении X.
Т.е. предупреждения про nullable лучше бы было показывать по месту создания X, а не в объявлении X.
V
(имхо)
IC
init не заставляет при инициализации задавать значение.
DP
Есть вариант написать = "" например
V
это не решает проблемы, что кто-то забудет проинициализировать значение. И лучше уж string.Empty
IC
Отключай #nullable или пиши каждый раз
= default!IC
А вообще лучше рекорды с конструкторами использовать, конечно.
V
к ним ещё привыкнуть нужно: научиться отличать от функций с кучей параметров.
V
и у такого вида setter'ов не будет
DP
То что с дто проблемс это было понятно изначально