Allow deep equality for collections in records

[dgolub]

Records are a great addition to the language and have the potential to save developers some time and avoid bugs by not having to write boilerplate code for things like equality. However, the behavior of the Equals method on collection classes doesn't mesh well with what many developers would want for their records, which is deep equality. Right now, if you want deep equality, you have to manually implement Equals and call SequenceEqual from LINQ on the collections in the record, which wastes the developer's time and has the potential to lead to bugs if they add a field and forget to add it to their implementation of Equals. I understand that the behavior on existing collection classes can't be changed due to the need to maintain backward compatibility. However, I see two ways that this issue could be addressed:

1. Add a new collection class called something like RecordList or DeepEqualList that override Equals to do deep equality. Similarly for DeepEqualDictionary, DeepEqualSet, etc.
2. Add an attribute called something like [DeepEqual] or [SequenceEqual] that can be applied to a field in a record (or even an entire record) to signal the compiler to generate code to call SequenceEqual on that field (or all fields of types implementing IEnumerable) in the implementation of Equals for the record.

[TahirAhmadov]

This is a great suggestion, especially your option 1 - although it probably belongs in runtime repo. In the meantime, you should be able to make your own collection types? I don't recall, are things like List<T>.Equals sealed? Hopefully not, in which case it's a simple child class; otherwise you can make a wrapper or a brand new implementation (both of these have downsides, obviously).

[CyrusNajmabadi]

Add an attribute called something like [DeepEqual] or [SequenceEqual] that can be applied to a field in a record (or even an entire record) to signal

Once at this point, you basically have a source generator. So the guidance would be: you can do this today, without any need for language change. Just package up these specialized equality constructs into their own analyzer/generator lib and you'll be good to go.

[huoyaoyuan]

• Collections are owned by the runtime, not the language.
• The definition of deep equality of collections is furthermore unclear. Sequence equality or set equality? Is duplicated items encountered?
• I don't even understand why to use Equals method.

[TahirAhmadov]

I highly doubt that the language can make this work, even if it wanted to, by looking at the member types like IEnumerable<T>, due to all of the reasons mentioned above. The only real solution is a library one: either BCL or custom types which inherit from List<T> etc. and implement Equals appropriately.

[TahirAhmadov]

PS. Realistically, the language could spit out code which tries casting the aforementioned IEnumerable<T> to things like IList<T>, etc., and perform certain pre-defined equality on those. However, that logic is extremely complicated and probably doesn't belong in the language.

[jnm2]

@CyrusNajmabadi In terms of performance it could be no different than how foreach lowers, and that might be seen as a plus. The presence of IEnumerable<T> or IReadOnlyCollection<T> would simply be markers to say "use sequence equality."

@ZacharyPatten Remember, I'm not arguing that this is a good thing. Only that it's not so far out of the realm of what C# does in other cases.

[ZacharyPatten]

@ZacharyPatten Remember, I'm not arguing that this is a good thing. Only that it's not so far out of the realm of what C# does in other cases

I thumbs downed it because there would need to be a lot more changes than just the ones you mentioned.

[jnm2]

@ZacharyPatten Can you elaborate on what changes would be needed in order for the compiler to decide whether or not to use sequence equality, set equality, or dictionary equality

The question I was answering didn't have anything to do with impl strategies:

How would the language know something is a set or not?

[sharwell]

Here's the approach I took:
DotNetAnalyzers/StyleCopAnalyzers@253d408

• Change the record parameter from T to EquatableValue<T>
• Construct the EquatableValue<T> with a custom equality comparer
• Expose the underlying T via an expression-bodied property

[alexandrehtrb]

Duplicated #4845

[RikkiGibson]

I see this as a distinct request. The linked request is asking for a change in the default behavior, while this request is for something in the platform to facilitate an alternative deep equality behavior.

In my opinion, the use case for immutable, cycle-free, deep-value-equatable records is a valuable one, so I am happy to see any improvements to the experience folks can achieve, through source generation, wrapper types, or whatever else.

[alexandrehtrb]

Maybe we could have a [DeepEquals] attribute over records, that would make Equals and GetHashCode with structural equality over collections.

[CyrusNajmabadi]

Maybe we could have a [DeepEquals] attribute over records, that would make Equals and GetHashCode with structural equality over collections.

This would already be possible that, without a need for anything from the language or Roslyn. You just need to write a source generator here that looks for this attribute and which generates the right equals/gethashcode methods.

[fabianoliver]

It has been mentioned, but that is exactly what Generator.Equals does. Personally, I've been using this one for a while now and am rather happy with that.

I'd of course love to have sensible structural collection equality for records out of the box, but given the different possible flavors (ordered equality, unordered equality, set equality, etc etc) I'm not sure something like that could even exist so an attribute-driven way might be the best thing we can achieve anyway!