C# 3.0 generic type inference - passing a delegate as a function parameter

后端 未结 5 1564
囚心锁ツ
囚心锁ツ 2020-11-27 05:34

I am wondering why the C# 3.0 compiler is unable to infer the type of a method when it is passed as a parameter to a generic function when it can implicitly create a delegat

5条回答
  •  孤城傲影
    2020-11-27 05:58

    Maybe this will make it clearer:

    public class SomeClass
    {
        static void foo(int x) { }
        static void foo(string s) { }
        static void bar(Action f){}
        static void barz(Action f) { }
        static void test()
        {
            Action f = foo;
            bar(f);
            barz(foo);
            bar(foo);
            //these help the compiler to know which types to use
            bar(foo);
            bar( (int i) => foo(i));
        }
    }
    

    foo is not an action - foo is a method group.

    • In the assignment statement, the compiler can tell clearly which foo you're talking about, since the int type is specified.
    • In the barz(foo) statement, the compiler can tell which foo you're talking about, since the int type is specified.
    • In the bar(foo) statement, it could be any foo with a single parameter - so the compiler gives up.

    Edit: I've added two (more) ways to help the compiler figure out the type (ie - how to skip the inference steps).

    From my reading of the article in JSkeet's answer, the decision to not infer the type seems to be based on a mutual infering scenario, such as

      static void foo(T x) { }
      static void bar(Action f) { }
      static void test()
      {
        bar(foo); //wut's T?
      }
    

    Since the general problem was unsolve-able, they choose to left specific problems where a solution exists as unsolved.

    As a consequence of this decision, you won't be adding a overload for a method and getting a whole lot of type confusion from all the callers that are used to a single member method group. I guess that's a good thing.

提交回复
热议问题