Equality: Equals, GetHashCode & IEquatable

var p1 = new Point(1, 2);
var p2 = new Point(1, 2);
Console.WriteLine(p1 == p2);       // False -- different objects, same data
Console.WriteLine(p1.Equals(p2));  // False -- same, unless Equals is overridden

Common follow-ups: How does this default behavior differ for value types like struct?

public struct Point { public int X, Y; }
var p1 = new Point { X = 1, Y = 2 };
var p2 = new Point { X = 1, Y = 2 };
Console.WriteLine(p1.Equals(p2)); // True -- structs compare by value by default

Common follow-ups: Why is the default reflection-based struct Equals() considered relatively slow, and how would you speed it up?

public class Point {
  public int X, Y;
  public override bool Equals(object? obj) =>
    obj is Point other && X == other.X && Y == other.Y;
  public override int GetHashCode() => HashCode.Combine(X, Y);
}

Common follow-ups: What specifically goes wrong in a Dictionary or HashSet if you override Equals() but forget GetHashCode()?

public struct Point : IEquatable<Point> {
  public int X, Y;
  public bool Equals(Point other) => X == other.X && Y == other.Y; // strongly-typed, no boxing
  public override bool Equals(object? obj) => obj is Point p && Equals(p); // delegates to the typed version
  public override int GetHashCode() => HashCode.Combine(X, Y);
}

Common follow-ups: Why does implementing IEquatable<T> matter MORE for structs than for classes, performance-wise?

public override int GetHashCode() => HashCode.Combine(FirstName, LastName, BirthDate);
// vs. the old, worse approach:
// public override int GetHashCode() => FirstName.GetHashCode() ^ LastName.GetHashCode(); // poor distribution

Common follow-ups: What happens with HashCode.Combine() if you need to combine MORE than 8 values, given its overloads are limited?

public class MutablePoint {
  public int X; // mutable field used in hashing -- dangerous!
  public override int GetHashCode() => X.GetHashCode();
}
var set = new HashSet<MutablePoint>();
var p = new MutablePoint { X = 1 };
set.Add(p);
p.X = 99; // mutated after insertion!
Console.WriteLine(set.Contains(p)); // False! -- 'lost' in the wrong bucket now

Common follow-ups: Why do many style guides recommend using immutable types (or records) specifically for Dictionary/HashSet keys?

public record Point(int X, int Y);
var p1 = new Point(1, 2);
var p2 = new Point(1, 2);
Console.WriteLine(p1 == p2);       // True -- value equality, auto-generated
Console.WriteLine(p1.Equals(p2));  // True

Common follow-ups: How would you override just ONE property's contribution to a record's auto-generated equality, if needed?

public class Shape {
  public override bool Equals(object? obj) =>
    obj != null && GetType() == obj.GetType() && EqualsCore((Shape)obj); // exact type match required
  protected virtual bool EqualsCore(Shape other) => true;
}
public class Circle : Shape {
  public double Radius;
  protected override bool EqualsCore(Shape other) => other is Circle c && Radius == c.Radius;
}

Common follow-ups: What subtle bug can occur if you use 'is BaseType' instead of an exact GetType() check in this scenario?

public class Money : IEquatable<Money>, IComparable<Money> {
  public decimal Amount;
  public bool Equals(Money? other) => other != null && Amount == other.Amount;
  public int CompareTo(Money? other) => Amount.CompareTo(other?.Amount ?? 0);
  // Equals and CompareTo agree: equal amounts -> Equals true AND CompareTo returns 0
}

Common follow-ups: What real bug can occur in a SortedSet<T> or SortedDictionary<TKey,TValue> if CompareTo() and Equals() disagree?

var list1 = new List<int> { 1, 2, 3 };
var list2 = new List<int> { 1, 2, 3 };
Console.WriteLine(list1.Equals(list2));           // False -- reference equality
Console.WriteLine(list1.SequenceEqual(list2));    // True -- explicit element-by-element comparison

Common follow-ups: Does SequenceEqual() also check that both sequences are the SAME LENGTH before comparing elements?