Wierd ambiguious call on overloaded function with a function parameter

Question

So say I've got a method which I've overloaded. One takes a function returning uints, one takes a function returning ints.

static void test1(Func<uint> f)
{
    //things
}
static void test1(Func<int> f)
{
    // also things
}

Now I try to call it like this:

test1(Random.FunctionThatReturnsUints);

but I get an ambiguous call error at compile time:

   Error    4   The call is ambiguous between the following methods or
    properties: 'RNG_Comparison.Run.test1(System.Func<int>)' and 'RNG_Comparison.Run.test1
(System.Func<uint>)'

What's up with that? Isn't the whole point of overloading a function for it to understand implicitly which one you mean based on the types? I mean, if I'd called it with a func returning BigInt or something, maybe I could see the compiler's confusion, but this one seems pretty cut and dried.

Does anyone know why I'm getting that error?

Try `test1(new Func(Random.FunctionThatReturnsUints))` and see if that results in a different compiler error. — cdhowie, Sep 26 '13 at 14:55
See answer from Eric Lippert on similar topic http://stackoverflow.com/a/2058854/961113 — Habib, Sep 26 '13 at 15:00

score 1 · Answer 1 · edited May 23 '17 at 12:11

1

Eric Lippert (a member of the C# team) called this sort of thing "one of the hairiest parts of the spec", so to fully answer "why does the compiler do this?" would be a hard question. Suffice to say, it's because the C# specification allows that to happen. This is an easy workaround:

test1(new Func<uint>(Random.FunctionThatReturnsUints));

edited May 23 '17 at 12:11

Community

1
1

answered Sep 26 '13 at 15:16

Tim S.

55,448
7
96
122

1

Thanks for the shout-out; I note that I am a *former* member of the C# language design and compiler development teams. – Eric Lippert Sep 26 '13 at 19:28

score 1 · Accepted Answer · edited May 23 '17 at 12:11

1

The important thing in the post by Eric Lippert cited by Tim is:

The principle here is that determining method group convertibility requires selecting a method from a method group using overload resolution, and overload resolution does not consider return types.

In your code there's method group conversion in action and that causes the problem. The proposed solution eliminates the problem.

edited May 23 '17 at 12:11

Community

1
1

answered Sep 26 '13 at 15:24

ilmatte

1,732
16
12

Yeah I read through that, interesting stuff. I get why it is the way it is. Thanks – NathanTempelman Sep 26 '13 at 15:37

Wierd ambiguious call on overloaded function with a function parameter

2 Answers2