Proposal: Implementing IComparable should implement comparison operators

[iDaN5x]

Implementing IComparable is sufficient for allowing comparison of two instances of class X.
It is, therefore, preferable that comparison operators (such as !=, =, <, <=, etc.) would be auto-implemented for X pairs when implementing IComparable.

Currently, large share of comparable classes features the following silly-looking pattern:

public static bool operator  < (Foo x, Foo y) { return CompareTo(x, y)  < 0; }
public static bool operator  > (Foo x, Foo y) { return CompareTo(x, y)  > 0; }
public static bool operator <= (Foo x, Foo y) { return CompareTo(x, y) <= 0; }
public static bool operator >= (Foo x, Foo y) { return CompareTo(x, y) >= 0; }
public static bool operator == (Foo x, Foo y) { return CompareTo(x, y) == 0; }
public static bool operator != (Foo x, Foo y) { return CompareTo(x, y) != 0; }

Moreover, by adding this feature, the following will be possible:

public void DoStuff<T>(T x, T y)  where T : IComparable {
    /* Not possible at the moment....
       Instead you're forced to use x.CompareTo(y) < 0
       Which is less readable */
    if (x < y) { 
        moreStuff();
    }
}

This is not such a drastic change but it'll be handy 😄

[svick]

At the very least, automatically overloading == would be a breaking change. If a class currently implements IComparable<T>, but doesn't overload ==, then using == on it will use reference equality. But your proposal would change that to value equality.

[HaloFour]

Even with generics that would be a breaking change. The following is legal today and does perform a reference equality check:

public static bool IsEquals<T>(T x, T y) where T : class, IComparable<T>
{
    return x == y;
}

If the compiler would instead invoke IComparable<T>.Compare that could result in a different value or a NullReferenceException.

[iDaN5x]

Was not considering this issue very deeply, and you're both definitely right.
This feature idea came to me while working, and I thought it could be nice to bring up.

Maybe it should be limited to <, <=, >, >=?
Not sure if this is worth the time and effort to implement at this form...
what do you think?

@svick @HaloFour

[alrz]

Probably #5165 or #258 and #5624 could reduce the verbosity of defining all these operators.

[AdamSpeight2008]

< <= == != => > should not be automagically be implemented via implementing IComparable or IComparable<T>. If you want to have the "comparision operators" you can support this by use a lifted type that does. Exts.Comparisions.Classes.Operators

Also what those operators actually mean in the context of that object should be left for the programmer designing those objects.

[gafter]

The proposed change would break existing programs.