Aren’t records pretty trivial to create as a custom class in C#?
https://sharplab.io/#v2:EYLgtghgzgLgpgJwDQBMQGoA+BYAUANwgQAI...
It’s also generating code for the main method, which is also a new c# 9 feature
I don't understand why properties have setters in the generated definition of the record. I'm missing something.
public int MyProp { get; init; }
public int MyProp { get; set; }
Records generate a lot of code when you compile them, including methods to compare by value.
The boilerplate required to do that in C# without records is extensive and hard to maintain. Even structs, which are supposed to be value objects, are not easy to compare by value.
I'll put it this way: records are important enough that I stopped using C# because it lacked something like records, and now I'm going to pick it up again.
You have to override Equals() and GetHashCode() for starters. Then you also need to make sure you only have getters and no setters (or private setters). In some cases you need to make your empty constructor private and force a specific constructor to be used. If you have multiple constructors it means you will have different invariants which puts you in class land, you are better off with classes then anyway. Also if your immutable objects have many methods..that also puts you in class land.
Just that alone makes it cumbersome.
So a new record type that behaves somewhat like a struct would be perfect. Or the F# way, which is basically perfection.
If you have just 50 immutable classes you have to replicate those 50 lines of boilerplate for each class and make sure it's bug free. It clutters your classes up and it's just plain gross.
It's going to be way better that the platform supports this kind of data structure natively instead of us building out the monstrosity ourselves.
By the way, plenty of the features of C# is basically syntax sugar, gets compiled down to more vebose code anyway. We think we write one or two lines of happy code, but underneath it might get turned into 20 lines. Luckily we mostly don't have to see/deal with it unless you are trying to squeeze your apps performance to the max (or have a nasty bug that cannot be caught by normal means), but at that point it might make more sense to use a lower level language.