Equality Is Hard

Reference equality is generally fine for mutable types, you probably only want value equality for immutable types. If you use value equality for mutable types, you start getting into trouble when you use them as e.g. hash keys.

    @FunctionalInterface
    interface Equivalence<T>
    {
        boolean equals(T one, T other);
    }

    @FunctionalInterface
    interface Comparison<T>
            extends Equivalence<T>
    {
        int compare(T one, T other);

        @Override
        default boolean equals(final T one, final T other)
        {
            return compare(one, other) == 0;
        }
    }

    @FunctionalInterface
    interface HashFunction<T>
    {
        int hashCode(T obj);
    }

    interface Equalitor<T>
            extends Equivalence<T>, HashFunction<T>
    {
    }

    interface Comparator<T>
            extends Comparison<T>, Equalitor<T>
    {
    }

    interface Equatable
    {
        Equalitor<? super Object> equivalence();
    }

    interface Comparable
            extends Equatable
    {
        @Override
        Comparator<? super Object> equivalence();
    }

    final class Objects
    {
        static int compare(final Object one, final Object other)
        {
            if (one == other)
            {
                return 0;
            }

            if (one == null)
            {
                return -1;
            }

            if (other == null)
            {
                return 1;
            }

            if (one instanceof Comparable oneCmp && other instanceof Comparable otherCmp)
            {
                final Comparison<? super Object> cmp = oneCmp.equivalence();

                if (equals(cmp, otherCmp.equivalence()))
                {
                    return cmp.compare(one, other);
                }
            }

            throw new SomeRuntimeException();
        }

        static boolean equals(final Object one, final Object other)
        {
            if (one == other)
            {
                return true;
            }

            if (one instanceof Equatable oneEq && other instanceof Equatable otherEq)
            {
                final Equivalence<? super Object> eq = oneEq.equivalence();

                if (equals(eq, otherEq.equivalence()))
                {
                    return eq.equals(one, other);
                }
            }

            return false;
        }

        static int hashCode(final Object obj)
        {
            if (obj instanceof Equatable objEq)
            {
                final HashFunction<? super Object> hf = objEq.equivalence();
                return hf.hashCode(obj);
            }

            return someIntrinsicHashCode(obj);
        }
    }

No, actually, it doesn't make sense in general. Due to padding, structs may have arbitrary meaningless bytes between the actual data fields, and memcmp will break on those. It works because structs are often filled with zeroes on initialization, but it isn't required or enforced in any way. I was burnt by this problem more than once, not really fun to debug

[1] https://doc.rust-lang.org/book/ch05-02-example-structs.html#...

[2] https://doc.rust-lang.org/std/cmp/trait.PartialEq.html#how-c...

There is a distinction between intensional Martin Lof type theory and extensional Martin Lof type theory, which differ in their treatments of equality. First, one must distinguish between judgmental equality x = y, which is a statement in the mathematical metalanguage that two terms are equal, and propositional equality, which "internalizes" judgmental equality within the programming language through the equality type Id(A, x, y), the type of proofs that x and y are judgmentally equal. In extensional type theory, judgmental equality also follows from propositional equality, and together with the eta-conversion rule for functions, function extensionality is provable [0]. However, typechecking extensional type theory is undecidable [1].

Alternatively, in Homotopy Type Theory (HoTT), supports function extensionality is provable from the univalence axiom, which states that isomorphic types are equal [2]. Function extensionality is trivially provable in Cubical Agda [3], which gives a computational interpretation of HoTT's notion of equality.

[0] https://cstheory.stackexchange.com/questions/46331/extension...

[1] https://cs.stackexchange.com/a/112559

[2] https://ncatlab.org/nlab/show/function+extensionality#relati...

[3] https://agda.readthedocs.io/en/v2.6.0.1/language/cubical.htm...

It is certainly a big hammer, but as theoretical computer science tools go, it is pleasingly easy to use. Unfortunately it is pleasingly easy to use in much the same way high explosives are pleasingly easy to blow yourself up with, as it annihilates so many things that we'd rather like to keep. But, still... easy to use.