为什么具有返回类型的方法不能与返回void的具有相同签名的委托匹配？

Question

I'm rather curious about this limitation of C# delegates. Take the following code, which does not compile:

class Program
{
   delegate void Foo(string s);

   static void Main(string[] args)
   {
      Foo f = Test; // Error
      f("Hello");
   }

   static int Test(string s)
   {
      return s.Length;
   }
}

The error here is that the delegate Foo does not have a return type, thus cannot be used to create a reference to the function Test .

However, why is this a problem? Obviously, if one were to call Test through the delegate f , they would not have access to Test 's return value, which is perfectly fair, but it seems to me that the compiler could still generate type safe code by simply ignoring the return value, perhaps even being able to optimize that case.

Obviously, if the situation were reversed, and Foo specified a string be returned and Test returned void , we'd have a problem. So, I fully agree that that case should result in a compiler error. However, why can't int Test(string) implicitly match the delegate void Foo(string) ?

I'm looking for one of two possible answers: One, a logical issue with allowing this ability. Is there a case where ignoring the return type when calling a method through a delegate would cause an unsafe condition? Or, two, a reference to the C# specification that clarifies why this implementation would violate the spec.

Answer 1

The C# specification (section 15.2 Delegate Compatibility) had this to say.

A method or delegate M is compatible with a delegate type D if all of the following are true:

...

· An identity or implicit reference conversion exists from the return type of M to the return type of D.

There is no such conversion between any type and void, so this should not be allowed according to the spec.

It may very well be that it could be logically done, I'm not sure, but there may not have been a big enough use case for it compared to other features. It's also fairly easy to create a wrapper for that yourself, which also lessens the use case need.

public Action Ignore<T>(Func<T> call)
{
    return () => call();
}