Equality comparison for records with reference properties

[Kralizek]

I love records. Until I hate them.

In my project I use them mostly as DTO to serialize/deserialize responses from the backend.

This one specific record is mostly strings, bools and enums and equality comparison just worked fine.

Then we needed to add a property which was a string array and the comparison broke.

I know exactly where and why it broke and how to fix it.

It's just annoying that I go from 0 code to a massive overridden method because of one property.

I know the language team often try to work out scenarios like this one where one small change tips the scale massively.

So this post is just to hope the team sees this message and thinks there's something that can be done to avoid having to override the whole equality comparison process and just specify how the "offending" property should be handled.

I couldn't find similar discussion but the following are somehow related: #5767, #4845

[CyrusNajmabadi]

It's just annoying that I go from 0 code to a massive overridden method because of one property.

You don't need that. Just use a type like EquatableArray

[Kralizek]

Thanks for answering. I unmarked your post as the answer because while EquatableArray solves the specific issue, it's a bit like looking at the finger of someone pointing at the moon.

The "slope" exists whenever a custom equality comparer needs to be introduced within the mix.

[CyrusNajmabadi]

The same solution applies there as well. Just wrap the type with one that has the custom equality semantics you need. EquatableArray demonstrates teh general solution to the problem.

[En3Tho]

@Kralizek It's a deeper problem than it might seem at glance. You're right about EquatableArray solving a very specific problem but that's how you clearly indicate how you want your data to be compared.

How far do you want compiler to go trying to generate an "optimal" equality behavior?

Do you want to have special recognition of specific types? How many of those and how many combinations?

Do you want record equality and default comparer equality to be different? e.g. array1 == array2 or EqualityComparer.Default.Equals(array1, array2) will not be the same as record(array1) == record(array2)

What if you have an array of arbitrary objects?

What if you need equality contract based on external data?

All of these things are simply solved with a custom type which exposes equality contract you provide. It's a cheap price to pay compared to all of the quirks automatic "smart" equality generation might introduce.

[Kralizek]

Shooting solutions here:

A generic compiler-blessed attributes that can be used to decorate a property and specify a IEqualityComparer<T> to be used when comparing instances of the parent type when the compiler is generating the Equals method.

public record Something
{
   public int Property1 {get; init;}
   public string Property2 {get; init;}

   [EqualityComparer<SomeTypeComparer>]
   public SomeType Property1 {get; init;}
}

The Something.Equals would then just use an instance of the SomeTypeComparer when comparing two instances of SomeType.

[En3Tho]

How would comparer be constructed? What if you need equality contract based on external data? question is about this thing basically.

[En3Tho]

Attribute based approach can be implemented with a source generator. You can define any rules you want but I doubt you can come up with really good set of generic rules that would beneffit everyone.