runtime: ImmutableArray struct implements IEquatable interface but does not stick to the rules of properly implementing value semantics

(Partially unrelated) Just wanted to say that while I agree that of course changing the behavior of IEquatable<T> here is definitely a breaking change and not doable, the current behavior is indeed extremely unfortunate when using lots of records like @RikkiGibson mentioned. This is extremely common when writing source generators (as incrementa generators require you to define models for your incremental steps), and the current situation is that the second you have even a single record parameter that’s an immutable array, you just fall off a cliff and have to go all the way down to implementing equality manually for the whole record type, which is a pain. It would be nice if there was some way to improve this scenario, as it’s arguably pretty common and unfortunately (1) extremely verbose and (2) extremely error prone, as if you don’t know this behavior or just forget when refactoring, you’ll silently break your entire incremental pipeline after that step 😅

As @RikkiGibson and @Sergio0694 already mentioned the current equatable behavior of the ImmutableArray<T> struct - whether this was intended or not - is a pitfall, unfortunately.

At least I have experienced this on heavily utilizing records (e.g. when working with DDD or object-functional techniques that involve a lot of immutability and types that come with value semantics). So I was introducing new records representing composites that own their contained collections. Then I was looking for some out-of-the-box immutable collection and the ImmutableArray<T> was the only one I could find which is implementing the IEquatable<T> interface. After replacing a custom immutable collection type that comes with value semantics the corresponding specs and tests were broken. So I digged a bit deeper and detected that the ImmutableArray<T> was actually not what I thought it is, according to its name and implementation of the IEquatable<T> interface. It looks like @Sergio0694 came across a similar situation. 😅

@eiriktsarpalis I know that changing this behavior afterwards would be a breaking change. In my opinion it would be great if there was an out-of-the-box immutable collection or bare enumerable implementation that comes with value semantics and can be used within records.

@mrpmorris Create your own type(s) that capture the symbol info you want and copy those over.

Just wanted to mention that this issue keeps popping up very often whenever I see people writing source generators (myself included). I had to copy-paste my EquatableArray<T> type in over 4 different projects for the same reason, and it’s just not ideal. This feels like a common enough issue for source generator authors that it’d be nice if this could either be addressed in ImmutableArray<T> itself, or maybe we should propose a separate API that could be used in these cases? I know some other generator authors (eg. @jkoritzinsky) have alternative solutions to this, but it just seels like everyone is reinventing ways to solve the same issue, so maybe just having a proper solution available for everyone would be better? 🤔

“it would be great if there was an out-of-the-box immutable collection or bare enumerable implementation that comes with value semantics and can be used within records.”

You know what, that’s… Actually a very good idea. I reckon using something like that might very well make authoring records much much simpler, as there would be no more a need to handroll custom comparers every single time 🤔

I’ve hacked together really quick just to play around:

public readonly struct EquatableArray<T> : IEquatable<EquatableArray<T>>
    where T : IEquatable<T>
{
    private readonly T[] array;

    public bool Equals(EquatableArray<T> array)
    {
        return AsImmutableArray().SequenceEqual(array.AsImmutableArray());
    }

    public override bool Equals([NotNullWhen(true)] object? obj)
    {
        return obj is EquatableArray<T> array && Equals(this, array);
    }

    public override int GetHashCode()
    {
        if (this.array is not T[] array)
        {
            return 0;
        }

        HashCode hashCode = default;

        foreach (T item in array)
        {
            hashCode.Add(item);
        }

        return hashCode.ToHashCode();
    }

    public ImmutableArray<T> AsImmutableArray()
    {
        return Unsafe.As<T[], ImmutableArray<T>>(ref Unsafe.AsRef(in this.array));
    }

    public static EquatableArray<T> FromImmutableArray(ImmutableArray<T> array)
    {
        EquatableArray<T> array2 = default;

        Unsafe.AsRef(in array2.array) = Unsafe.As<ImmutableArray<T>, T[]>(ref array);

        return array2;
    }

    public static implicit operator EquatableArray<T>(ImmutableArray<T> array)
    {
        return FromImmutableArray(array);
    }

    public static implicit operator ImmutableArray<T>(EquatableArray<T> array)
    {
        return array.AsImmutableArray();
    }

    public static bool operator ==(EquatableArray<T> left, EquatableArray<T> right)
    {
        return left.Equals(right);
    }

    public static bool operator !=(EquatableArray<T> left, EquatableArray<T> right)
    {
        return !left.Equals(right);
    }
}

See updated code here.

And you’d use it like so:

record MyRecord(EquatableArray<string> Names, EquatableArray<int> Numbers);

ImmutableArray<string> names = GetNames();
ImmutableArray<int> numbers = GetNumbers();

MyRecord myRecord = new(names, numbers); // Implicit conversion

names = myRecord.Names;
numbers = myRecord.Numbers; // Also implicit conversion

I might actually try this out in a branch of the MVVM Toolkit and see how this goes 😄 It would seem like this would simplify a ton of code!

UPDATE: well this was an absolute success, this is amazing 🎉

The ImmutableArray<T> struct implements the IEquatable<T> interface but does not stick to the rules of implementing value semantics acoording to the IEquatable interface.

IEquatable<T> doesn’t require types implement deep value semantics. It implies no contract other than some loosely defined “equality” that’s up for interpretation by types that implement it. It’s not completely uncommon for either shallow equality or ignored properties to be common in implementations in C# or other languages.