Why does Object provide equals and hash code methods?

Many object-oriented programming languages where something like Object is the root of the type hierarchy provide some default equality and hash code methods; for example:

• C# System.Object: Equals and GetHashCode
• Java java.lang.Object: equals and hashCode

It is valuable to override these methods for objects that exhibit value semantics; for example, Boolean, Integer and Guid, but it is uncommon to override these methods for objects that exhibit behaviour semantics; for example services and controllers. These methods also serve as the mechanism to determine duplicates for Set<T> and Map<K, V> insertion.

Let's assume that Object does not contain these methods, and instead they are provided by interfaces; for example:

interface Equatable<T> {
    Boolean equals(T other)
}

interface Hashable {
    Integer getHashCode()
}

Now, objects that exhibit behaviour semantics don't implement the methods because they're not required, but objects that exhibit value semantics can implement them; for example:

class Guid : Equatable<Guid>, Hashable {
    public Boolean equals(Guid other) {
        ...
    }

    public Integer getHashCode() {
        ...
    }
}

Also Set<T> and Map<K, V> could declare constraints on T and K, such that objects should implement Equatable<T> and Hashable; for example:

interface Set<T> where T extends Equatable<T>, Hashable {
    ...
}

interface Map<K, V> where K extends Equatable<T>, Hashable {
    ...
}

Given that not all objects (i.e. those that exhibit behaviour semantics) require these methods to be overridden, it seems plausible that equals and hash code methods did not need to be declared at the root of the type hierarchy, so why are they defined at the root of the type hierarchy, rather than something expected to be implemented as required?

Is there some other underlying or fundamental reason that these methods are implemented at the root of the type hierarchy, and are there any similar languages where this isn't the case?

There is no fundamental reason they have to be implemented at the root, for all the reasons you mention. This answer will be specifically for c#, but I would guess many of the arguments apply to java as well.

We can only speculate why the language designers used this model, but it is likely influenced by the lack of generics in the first version of C#. Influence from java, that also lacked generics, may also have played a part. Note that in c# your proposed interface does exist in the form of IEquatable<T>.

However If I understand your argument correctly, HashSet would be constrained to IEquatable<T>. This would only be implemented for types using value equality. Therefore HashSet could not be used with types using reference equality, and this seem like an obvious problem. Dictionaries and HashSets are still very useful for objects using reference equality.

That is not to say I think the equality system, as it is now, is well designed. To compare two objects you may use

1. .Equals(object obj)
2. IEquatable<T>.Equals(T obj)
3. Equality operators, == / !=, (and each of these require explicit implementation)
4. IEqualityComparer<T>.Equals(T a, T b)

This is confusing for new developers, and tend to lead to a quite significant amount of boiler plate code. This, as many other things, is partially due to the language evolution. New features have to be carefully designed work with existing code. If c# where rewritten from scratch you could almost certainly make improvements, and that would likely include removal or redesign of .Equals(object obj). But that is not really feasible since it would break decades of existing code.

If you are designing a new language please do consider ways to handle equality better. But I would expect this to require some major design work to make it as easy to understand and use as possible while still allowing for necessary flexibility. Designing languages is not easy! Looking around at other languages there are several that has problems in the equality area, C# is at least better than javascript.

As for similar languages, both java and c# where in some sense intended as an easier to use c++. And that just avoid the problem by not having a common type root at all. But there are some usability downsides with that approach.