Collections in records should be compared with value equality instead of reference equality

[sanderobdeijn]

One of the properties of a record is value equality, but when you use a collection in a record you break this expectation.

For example: here I would expect result to be true but it is false.

record Test(int[] A);

var test1 = new Test(new int[] { 1,2 });
var test2 = new Test(new int[] { 1,2 });
		
var result = test1.Equals(test2);

Using collections in a record also has some issues with immutability but I expect this could be fixed by using collection from the System.Collections.Immutable namespace.

[333fred]

See https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-06-02.md#records-with-circular-references.

[sanderobdeijn]

I read the meeting notes. And I don't understand what you are trying to say.
Could having collection reference equality lead to circular references?
Should we do this with source generators?

[333fred]

The meeting notes discussed both circular objects and other cases the user might want to adjust object equality, such as sequence equality, string comparison, etc. The conclusion is applicable to all those cases.

[En3Tho]

As a workaround you can implement a struct wrapper like ArrayEquatable which will wrap an array and compare elements one by one. I guess it is not ideal but if you value structured array equality then you need to make something like that a domain type.

[ZacharyPatten]

Not every collection uses the same comparer. Arrays don't have a IEqualityComparer<T>, but HashSet<T> and many other collections do. What would you expect to happen in a case where you want value equality check for a collection, but the two collections you are checking aren't using the same comparing/equality checks?

For arrays and collections that don't have IEqualityComparer<T>s, this wouldn't be an issue, but if you implemented a value equals for them and not other collections, you would end up with a very confusing code base where the Equals method doesn't work the same on all collection types.

Value based collection equality methods should exist, but in my opinion using Equals is not the most appropriate way to achieve that. It is easy to make your own methods that do the equality check how you want it to be done.

[sanderobdeijn]

Ok but then the documentation probably has to be updated to include that value equality in records breaks when a collection in a record is used.
And if value equality with records is required, custom logic is needed.

The first check in record equality is the equalitycontract check. From my understanding this would ensure that records of 2 different types are always not equal. So comparisons are only made between 2 equal types. I would also expect that the collection types are the same then.

[Richiban]

TBH I think the correct response here it what F# does: you get a compiler warning if you put non-equatable reference types inside a record.

[HaloFour]

I think that sounds like an excellent suggestion for https://github.com/dotnet/roslyn-analyzers

[sanderobdeijn]

Just taking a step back, I understand there are technical issues that would complicate implementing this feature.

Functionally, if we say that record equality is determined by the values in the record, would you expect that the equality of all the properties in that record are value based.

@Richiban suggestion about compiler warnings makes sure you don't break the value equality expectation.

But that means you can't use a list (I mean the generic term not the c# class) of values in a record. That would be a shame, I can imagine use cases for implementing valueobjects (in a ddd context) that have a list of other values or valueobjects.

Would this mean we need a new list structure for records, a recordlist that is immutable and has default value equality?

[theunrepentantgeek]

A new list type with value based equality doesn't fix the underlying issue of infinite loops and stack overflow errors.

Imagine you had a list type that implemented value equality semantics - let's call it ValueList for simplicity.

Now, let's capture relationships between four people:

public record Person(
    string FullName,
    string KnownAs,
    string FamilyName, 
    ValueList<Person> Parents, 
    ValueList<Person> Children);

Person alice = new() {
    FullName = "Alice Appleby",
    KnownAs = "Alice",
    FamilyName = "Appleby",
    Parents = ValueList<Person>.Empty,
    Children = ValueList<Person>.Empty,
};

Person bob = new() { /* elided */ }
Person catherine = new() { /* elided */ }
Person david = new() { /* elided */ }

alice.Children.Add(catherine, david);
bob.Children.Add(catherine, david);
catherine.Parents.Add(alice, bob);
david.Parents.Add(alice, bob);

Finally, let's create one more person:

Person mother = new() {
    FullName = "Alice Appleby",
    KnownAs = "Alice",
    FamilyName = "Appleby",
    Parents = ValueList<Person>.Empty,
    Children = new(catherine, david),
};

Think about what happens if you evaluate alice.Equals(mother). You might expect to get a true result, as both instances have the exact same structure.

• All the simple properties of alice and mother are the same
• The Parents property of both is empty
• So we need to compare Children.
• Is catherine.Equals(catherine) true?
• All the simple properties of catherine and catherine are the same
• The Children property of both is empty
• So we need to compare Parents.
• Is alice.Equals(alice) true?

And so we've entered an infinite loop that will only be terminated by a stack overflow. 💥

IIRC, the C# team considered these scenarios in depth when designing records. Automatically generating code that won't go into a recursive loop like this is possible, but imposing that overhead on every record type would be considerable runtime overhead.

Automatic support for nested container types (such as list, collection, set, dictionary) creates a deep pit of failure for developers, one that's very easy to fall into. Forcing developers to handle these cases themselves imposes a low overhead, while avoiding major problems.

The existing solution is a pretty good one - write your own Equals(T) method to get the semantics you want. In the simple case you can use Enumerable.SequenceEqual(). This approach is also how you'd make the string comparisons case insensitive, so that "Alice" and "alice" are considered equal.

[rlundy]

So then (two years later!) this is a documentation issue, because here...

https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/record#value-equality

...it doesn't say anything about a record's value equality not applying to collections inside the type.

I've submitted documentation feedback, and @sanderobdeijn, I encourage you to as well.

[CyrusNajmabadi]

...it doesn't say anything about a record's value equality not applying to collections inside the type.

It does apply value-equality to all members. It leaves it to the particular member/type to determine what equality means. If a member/type feels that equality is deep or shallow is up to that type itself.

[izolyomi]

I've also just encountered this issue and find it very misleading that value equality semantics are not applied by default to collections inside records. I'd also accept a compiler error instead, but the current behavior is completely against the original intentions of record types.

[Richiban]

@izolyomi I get that some developers might be surprised by the behaviour, but it's consistent with the rest of dotnet and, in my opinion, correct.

Records do not (and have never) promised deep equality; in dotnet every type is responsible for its own equality and so records defer to each of the contained values as to whether they should be considered equal or not. It's the same for ToString; would you also expect the record type to take control of how each of its properties should be converted to a string?

If you want collections with structural equality, my recommendation would be to create a struct wrapper that implements equality how you would like. Here's a quick and dirty example:

using System;
using System.Collections;
using System.Collections.Generic;
using System.Linq;

var a = new EqList<string>(["a", "b"]);
var b = new EqList<string>(["a", "b"]);

Console.WriteLine(a.Equals(b));

public struct EqList<T> : IReadOnlyCollection<T>, IEquatable<EqList<T>>
    where T : IEquatable<T>
{
    private readonly IReadOnlyCollection<T> _items;
    
    public EqList(IReadOnlyCollection<T> items) 
    {
        _items = items;
    }
    
    public int Count => _items.Count;
    
    public bool Equals(EqList<T> other) 
    {
        if (other.Count != this.Count)
            return false;
            
        if (Object.ReferenceEquals(_items, other._items))
            return true;
            
        foreach (var (left, right) in _items.Zip(other._items))
        {
            if (!left.Equals(right))
                return false;
        }
        
        return true;
    }
    
    public IEnumerator<T> GetEnumerator() => _items.GetEnumerator();
    IEnumerator IEnumerable.GetEnumerator() => _items.GetEnumerator();
}

PS I would argue that a compiler warning is appropriate on record definitions that include properties of types that don't implement IEquatable, the same as F# does.

[AndersKehlet]

@izolyomi - Rather than changing the collection type, another approach could be to change the equals implementation on the record. May seem tedious, but it's an archetypical case for source generators.

First result on google: https://github.com/diegofrata/Generator.Equals

[dersia]

I came across this recently, just because my expectations were differently. after reading through all the comments and understanding, why this is an issue and why it was implemented that way, I'd still like to make a comprised proposal for this.

we mainly use records as DTOs/POCOs/pure Datatyps and as such we limit those to value type properties. if we really need reference types in one of our records, I thin it makes total sense that we have to implement the equals method ourselves, since only we know how to compare such complex types best.

my proposal would be that equality for collections of value types would be implemented by the language/runtime. so adding an EqualityComparer<int>.RecordsDefault (because there is already a default EaualityComparer<int>) to the runtime that does something like SequenceEqual(other) for all value types and strings. and then adding this to the records equality method.

this would allow for simple records with list to work quite well and I think from a JSON de-/serialization point of view that is also how I would expect it to work. Reference Type (complex types) properties should always be compared using their own compare.

would there be support at least for this?

[alexandrehtrb]

I am in favour of deep equality for collections in records.

Kotlin language also has records, called "data classes". In Kotlin, array equality is reference-based, whilst list equality is structurally-based. If you want a deep collection equality in your data classes, you can use lists instead of arrays.

From Stack Overflow answer:

// kotlin code

val list1 = listOf(1, 2, 3)
val list2 = listOf(1, 2, 3)

val array1 = arrayOf(1, 2, 3)
val array2 = arrayOf(1, 2, 3)

// side note: using a==b is the same as a.equals(b)

val areListsEqual = list1 == list2 // true
val areArraysEqual = array1 == array2 // false

I understand that changing existing classes like List for deep equality could be troublesome, but maybe we could have a DeepEqualsList?

[HaloFour]

That could always be implemented as an extension method and/or a custom implementation of IEqualityComparer<List<T>>.