Proposal: Auto implemented operators for equality and comparison

[Neo-Ciber94]

Motivation

When implementing IEquatable<T> and/or IComparable<T> a class can end with a lot of code repeating the same.

public struct Number : IEquatable<Number>, IComparable<Number>
{
    private long Value {get; }
    public Number(long value) => Value = value;

    public bool Equals(Object other) => other is Number && Equals((Number)other);
    public bool Equals(Number other) => other.Value == Value;
    public static bool operator ==(Number n1, Number n2) => n1.Equals(n2);
    public static bool operator !=(Number n1, Number n2) => !(n1 == n2);
    
    public int CompareTo(Number other) => Value.CompareTo(other.Value);
    public static boolean operator >(Number n1, Number n2) => n1.CompareTo(n2) > 0;
    public static boolean operator <(Number n1, Number n2) => n1.CompareTo(n2) < 0;
    public static boolean operator >=(Number n1, Number n2) => n1.CompareTo(n2) >= 0;
    public static boolean operator <=(Number n1, Number n2) => n1.CompareTo(n2) <= 0;
}

Why the compiler don't just generate all the non-implemented operators for me when implementing IEquatable<T> and/orIComparable<T>?

So this:

public struct Number : IEquatable<Number>, IComparable<Number>
{
    private long Value {get; }
    public Number(long value) => Value = value;

    public bool Equals(Number other) => other.Value == Value;
    public int CompareTo(Number other) => Value.CompareTo(other.Value);
}

Its trasladated to this:

public struct Number : IEquatable<Number>, IComparable<Number>
{
    private long Value {get; }
    public Number(long value) => Value = value;

    public bool Equals(Number other) => other.Value == Value;
    public int CompareTo(Number other) => Value.CompareTo(other.Value);

    //Compiler Generated (Equality)
    public bool Equals(Object other) => other is Number && Equals((Number)other);
    public static bool operator ==(Number n1, Number n2) => n1.Equals(n2);
    public static bool operator !=(Number n1, Number n2) => !(n1 == n2);
    
    //Compiler Generated (Comparison)
    public static boolean operator >(Number n1, Number n2) => n1.CompareTo(n2) > 0;
    public static boolean operator <(Number n1, Number n2) => n1.CompareTo(n2) < 0;
    public static boolean operator >=(Number n1, Number n2) => n1.CompareTo(n2) >= 0;
    public static boolean operator <=(Number n1, Number n2) => n1.CompareTo(n2) <= 0;
}

When the number of methods in an app should be considered an attribute for example [DisableAutoOperators] could be used to tell the compiler to not generate the operators in that type.

Issues

• Operators should be generated for child classes?

Related

#1832
#39

[HaloFour]

This would change the behavior if existing code and introduce breaking changes. Any such feature should definitely be opt-in.

[Neo-Ciber94]

This would change the behavior if existing code and introduce breaking changes. Any such feature should definitely be opt-in.

Where could break existing code? Compiler should only generate operators if aren't already implemented.

[HaloFour]

When types don't define an equality operator you can still use == to do reference equality. If existing types suddenly automatically were given equality operators those existing comparisons would silently change.

[YairHalberstadt]

I wish though that it had never been allowed to override both == and !=, Both > and <=, and both < and >=

[canton7]

Note that your suggested implementations aren't null-safe (which is all the more reason to somehow get the compiler to generate them -- lots of people don't implement them properly).

[BhaaLseN]

💭 I wonder if it would be worthwhile considering the Spaceship operator <=> proposed for C++20 here, since it roughly does something similar.

[MkazemAkhgary]

Proposing tank operator:

o[=^=]o

[fanoI]

As a "compromise" could Roslyn generate them when the light bulb is pressed? If I remember correctly it already does but the generated methods simply throw NotImplementedException.

[CyrusNajmabadi]

As a "compromise" could Roslyn generate them when the light bulb is pressed? If I remember correctly it already does but the generated methods simply throw NotImplementedException.

@fanoI PRs welcome.

[VBAndCs]

When types don't define an equality operator you can still use == to do reference equality. If existing types suddenly automatically were given equality operators those existing comparisons would silently change.

We can add some [AutoGenerateOperators] attribute to the CompareTo method, so this new behavior is totally intended and controlled and breaks nothing.

[HaloFour]

@VBAndCs

That will certainly be a reality with Source Generators.