Operator '==' can't be applied to type T?

Question

I thought this method was valid but I was wrong:

static void Equals<T>(T x, T y)
{
    return x == y;    //operator == can't be applied to type T
}

After reading the specifiation (§7.2.4 in v3.0 and §7.3.4 in v4.0):

7.2.4 Binary operator overload resolution

An operation of the form x op y, where op is an overloadable binary operator, x is an expression of type X, and y is an expression of type Y, is processed as follows:

• The set of candidate user-defined operators provided by X and Y for the operation operator op(x, y) is determined. The set consists of the union of the candidate operators provided by X and the candidate operators provided by Y, each determined using the rules of §7.2.5. If X and Y are the same type, or if X and Y are derived from a common base type, then shared candidate operators only occur in the combined set once.

• If the set of candidate user-defined operators is not empty, then this becomes the set of candidate operators for the operation. Otherwise, the predefined binary operator op implementations, including their lifted forms, become the set of candidate operators for the operation. The predefined implementations of a given operator are specified in the description of the operator (§7.7 through §7.11).

• The overload resolution rules of §7.4.3 are applied to the set of candidate operators to select the best operator with respect to the argument list (x, y), and this operator becomes the result of the overload resolution process. If overload resolution fails to select a single best operator, a compile-time error occurs.

In step 2 I think this predefined implementation should be applied:

bool operator ==(object x, object y);
bool operator !=(object x, object y);

since everything in C# derives from Object. How can a compile-time error occurs in step 3? I don't think it's possible that "overload resolution fails to select" in this case.

EDIT The question came to my mind when I was implementing something like this:

class EnumComparer<TEnum> : IEqualityComparer<TEnum>
{
    public bool Equals(TEnum x, TEnum y)
    {
        return x == y;
    }
    public int GetHashCode(TEnum obj)
    {
        return (int)obj;
    }
}

I'm afraid I need to build a expression and invoke it dynamicly in Equals method.

Amaty

possible duplicate of c# compare two generic values – Jacobsen

FWIW, (object)x == (object)y is valid -- but consider (object)1 == (object)1 as a reason for not desiring this. Just need to help T along to a non-generic. – Smallish

The discussion is a bit abstract, but Eric Lippert has pointed out that it is a general misconception that everything derives from Object. blogs.msdn.com/b/ericlippert/archive/2009/08/06/… A relevant point he mentions is that type parameters do not derive from anything. – Chintzy

@pst: I think (dynamic)x == (dynamic)y is what you'd want here. Otherwise it just does a reference equality. – Tittivate

Right; type parameters are compile-time types that are always convertible to object, but it's a stretch to say that they have any sort of "inheritance" relationship. – Lengthy

I'm somewhat confused; why is the built-in implementation of equality on enums not sufficient? That is, why not just use the default equality comparer? – Lengthy

@Eric the built in equality compared on enums (at least up to 3.5) is horrid in performance terms in that it allocates each time. We've had to adults our own generic one in C++/CLI to do reinterpret casts to get decent performance when using generics which are enums. – Carley

it appears that the BCL designers 'fixed' this in 4.0 which is great, but only for the int cases, which leaves us in the same situation, but at least C++/CLI lets you do pretty anything you want if you're happy with the risk. – Carley

@ShuggyCoUk: You are correct. That's why I asked another question: #5829941 – Amaty

Answer 1

Good for you for reading the spec, but you stopped reading too soon. Had you read further you would have gotten to this bit:

---

The predefined reference type equality operators require one of the following:

• Both operands are a value of a type known to be a reference-type or the literal null. Furthermore, an explicit reference conversion exists from the type of either operand to the type of the other operand.

• One operand is a value of type T where T is a type-parameter and the other operand is the literal null. Furthermore T does not have the value type constraint.

Unless one of these conditions are true, a binding-time error occurs. (*)

---

The error isn't from overload resolution; the error is that overload resolution would have chosen the predefined reference type equality operator, and you don't have reference types.

Consider your code. What stops T from being a value type with no equality operator defined on it? Nothing. Suppose we fell back to the object version; both operands would box to different locations and therefore be reference-unequal, even if they had the same content. Since that is slow, confusing and wrong, it is illegal to even try.

Why are you trying to do this thing in the first place? If your method worked, which it doesn't, then your method would be worse than simply using == in the first place. What is the value you intend to add to the world with this method?

---

(*) I've reported the grammatical error in this sentence to the spec maintainers.

Lengthy

Thanks for your answer. See my edit to know how this question comes to my mind. – Amaty

See related question: #5829941 – Amaty

Answer 2

That would possibly work if it knew that where T : class, doing a reference comparison. Operators generally have very little support with generics, but there are workarounds. MiscUtil offers indirect support for operators on generics, otherwise EqualityComparer<T>.Default.Equals(x,y) is a good choice.

Pisciform

Thanks! I just want to implement a comparer for enums. See my edit. – Amaty

@Danny - try EqualityComparer<T>.Default.Equals(x,y) then – Pisciform

LOL!I was in the wrong direction! Thanks very much for the suggestion! – Amaty

Hi Marc, the implementation of EqualityComparer<TEnum>.Default.Equals(x,y) looks like x == y or x.Equals(y)?(the source code didn't tell me).The latter will cause a boxing right? – Amaty

@Danny no boxing if it implements IEquatable<T> - but I've just checked, and annoying this isn't the case for the enum. Grrr! I could write one that works via meta-programming if you really want (some ILGenerator action) – Pisciform

@Marc: A related question of mine: #5829941 – Amaty

@Marc, dropping to C++/CLI lets you do a nice switch in the static constructor based on the backing type and then use reinterpret casts even on generic type variables. c# won't let you directly. We found that easier than codegen... – Carley

Answer 3

I like using EqualityComparer<T>.Default for this.

It is based on the overridden Equals method, but uses IEquatable<T> when available, avoiding boxing on value types implementing it.

EqualityComparer<T>.Default.Equals(x, y)

Locker

Answer 4

use .Equals() method and be sure that the T implement IComparable

Knighthood

IComparable[<T>] is ordering; Equals (with GetHashCose() and optionally IEquatable<T>) is equality. – Pisciform