Question

Simplified from this question and got rid of possible affect from LinqPad(no offsensive), a simple console application like this:

public class Program
{
    static void M() { }    
    static void Main(string[] args)
    {
        Action a = new Action(M);
        Delegate b = new Action(M);
        Console.WriteLine(a == b);      //got False here
        Console.Read();
    }        
}

The “false” results from the operator ceq in CIL of the code above(visit the original question for details). So my questions are:

(1) Why == is translating to ceq instead of call Delegate Equals?

Here I don’t care about the (un)wrapping between Delegate and Action. At the very last, when evaluating a == b, a is of type Action while b is a Delegate. From the spec:

7.3.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.3.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.8 through §7.12).

• The overload resolution rules of §7.5.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 binding-time error occurs.

7.3.5 Candidate user-defined operators

Given a type T and an operation operator op(A), where op is an overloadable operator and A is an argument list, the set of candidate user-defined operators provided by
T for operator op(A) is determined as follows:

• Determine the type
T0. If T is a nullable type, T0 is its underlying type, otherwise T0
is equal to T.

• For all operator op declarations in T0 and all lifted
forms of such operators, if at least one operator is applicable
(§7.5.3.1) with respect to the argument list A, then the set of
candidate operators consists of all such applicable operators in T0.

• Otherwise, if T0 is object, the set of candidate operators is empty.

• Otherwise, the set of candidate operators provided by T0 is the set
of candidate operators provided by the direct base class of T0, or the
effective base class of T0 if T0 is a type parameter.

From the spec, a and b have a same base class Delegate, obviously the operator rule == defined in Delegate should be applied here(the operator == invokes Delegate.Equals essentially). But now it looks like the candidate list of user-defined operators is empty and at last Object == is applied.

(2) Should(Does) the FCL code obey the C# language spec? If no, my first question is meaningless because something is specially treated. And then we can answer all of these questions using “oh, it’s a special treatment in FCL, they can do something we can’t. The spec is for outside programmers, don’t be silly”.

Answer 1

There are two types of operators: user-defined operators and predefined operators. Section 7.3.5 “Candidate user-defined operators” does not apply to predefined operators.
For example, the operators on decimal look like user-defined operators in a decompiler, but C# treats them as predefined operators and applies numeric promotion to them (numeric promotion is not applied to user-defined operators).

Section 7.10.8 “Delegate equality operators” defines operator ==(Delegate, Delegate) as a predefined operator, so I’d think that all the rules about user-defined operators don’t apply to this operator (although this isn’t 100% clear in the spec as in this case, the predefined operator doesn’t apply whenever the user-defined operator would).

Every delegate type implicitly provides the following predefined comparison operators: 
bool operator ==(System.Delegate x, System.Delegate y);
bool operator !=(System.Delegate x, System.Delegate y); 

But System.Delegate itself is not considered a delegate type, so the only candidate for overload resolution is operator ==(object, object).