[Proposal]: Use CompareTo to resolve missing comparison operators

[VBAndCs]

Given this class that implements the IComparable:

class Test : IComparable< int>{

    public int Value;
        public int CompareTo(int other) {
            return Value.CompareTo(other);
       }
    }

Why can't c# use to the CompareTo method to resolve the comparison operators?

var f = new Test() { Value = 1};
Console.WriteLine( f == 1);
Console.WriteLine( f != 1);
Console.WriteLine(f > 1);
Console.WriteLine(f >= 1);
Console.WriteLine(f < 1);
Console.WriteLine(f <= 1);

which can be loqered to:
var f = new Test() { Value = 1};
Console.WriteLine(f.CompareTo(1) == 0);
Console.WriteLine(f.CompareTo(1) != 0);
Console.WriteLine(f.CompareTo(1) == 1);
Console.WriteLine(f.CompareTo(1) != -1);
Console.WriteLine(f.CompareTo(1) == -1);
Console.WriteLine(f.CompareTo(1) != 1);

[PathogenDavid]

Since this isn't a fully-specified language proposal, it should've been opened as a discussion.

Personally I'm not a fan, and I don't think this could be introduced without it being a breaking change. It seems like a good candidate for a source generator to me.

[VBAndCs]

think this could be introduced without it being a breaking change

How? The code doesn't compile today, so it can't break anything.
And if there is an overloaded comparison operator, it will take precedence, so, ole code will run as usual.

[HaloFour]

@VBAndCs

The code doesn't compile today

It does for the equality operator.

[VBAndCs]

It does for the equality operator.

No, it doesn't (.net core 3.1).

[PathogenDavid]

Yes it does. You'd be changing the meaning of == from reference equality to use IComparable.

See this example where TestWith4119 is using CompareTo for operator== as you're requesting. They don't have the same result.

[VBAndCs]

@PathogenDavid
Still will not break anything. My suggestion takes place when there is no way to resolve the operator, so, the compiler starts looking if the object implements Icompareable as the last resort, so, I don't want to change any existing rules. My motivation here was this issue dotnet/roslyn#49095. C# doesn't suffer with arithmetic operators, but still has an issue with comparisons.

[PathogenDavid]

Ah, I missed the part where you were implementing IComparable<int> instead of IComparable<Test> in your example.

I feel like if you're going to go that route it's just going to be this weird inconsistency where this only works when comparing reference types and value types or value types with other value types.

In that issue you've mentioned you're auto-generating these types. Why not just auto-generate your operator overloads too?

[VBAndCs]

Why not just auto-generate your operator overloads too?

Recently. this seems to be the solution. But I wonder why can't the compiler deduce most of the operators if it has just enough info? In fact this doesn't apply only on CompareTo, but it is applicable also if the compiler has one of (= or !=) and on of (< or >), so it can use them to do the remain operators. And of course when inheriting base class operators they should be altered to deal with the child type, because it is useless now. The operator overloading needs a second look.