Assert.AreEqual when types A and B implements IEquatable<A> no longer works

[Evangelink]

If type A implements IEquatable<A> and type B also implements IEquatable<A> (yes of A), then you could call Assert.AreEqual(instanceOfA, instanceOfB) before and it would work, now T is expected to be either both A or both B, even though they could be "equatabled".

I mean it's questionable to compare two different types, but I haven't really seen this scenario discussed as breaking, so I thought I mention it here. Guess, I'll have to convert on the test, rather than inside the Equals functions.

class A : IEquatable<A>
{
    public bool Equals(A other) { ... }
}

class B : IEquatable<A>
{
    public bool Equals(A other) { ... }
}

// ...

[TestMethod]
public void Test()
{
    var instanceOfA = new A();
    var instanceOfB = new B();

    Assert.AreEqual(instanceOfA, instanceOfB);
}

Originally posted by @eXpl0it3r in #254 (comment)

[Evangelink]

@eXpl0it3r Thanks for the report, I definitely didn't consider this case. I guess we could simply add a new overload as public static void AreEqual<T>(IEquatable<T>? expected, IEquatable<T>? actual) and it would fix this case without breaking some other scenario (from what I can think of).

[Evangelink]

This is interesting case, I have never done this kind of equality. So with your example B.Equals(A) is true but A.Equals(B) is false. At least with the dumb implementation of having Equals(object obj) calling Equals(T t).

[eXpl0it3r]

We had a case that did a sort of conversion/simplification inside the equals method for mathematical objects, so both direction worked. Not sure I'd design it that way myself, as it seems to hide what's actually happening and thus makes it more error prone.

Thank you for the quick fix! ❤️ 🎉

[Evangelink]

We will be shipping the bugfix release this week (hopefully Wednesday).