Ambiguity with Action and Func parameter

Question

How is it possible that this code

TaskManager.RunSynchronously<MyObject>(fileMananager.BackupItems, package);

causes a compile error

The call is ambiguous between the following methods or properties:
'TaskManager.RunSynchronously<MyObject>(System.Action<MyObject>, MyObject)' and
'TaskManager.RunSynchronously<MyObject>(System.Func<MyObject, bool>, MyObject)'

when signature of the action is

public void BackupItems(MyObject package)

and "ambiguous" methods are

static class TaskManager
{
    public static void RunSynchronously<TInput>(Action<TInput> task, TInput param)
    {
        Task.Factory.StartNew(() => task(param));
    }

    public static bool RunSynchronously<TInput>(Func<TInput, bool> task, TInput param)
    {
        return Task.Factory.StartNew(() => task(param)).Result;
    }
}

It seems to me that there is an ample difference between these methods. What am I missing here?

EDIT:

Besides the accepted answer I just came across a solution in a similar question. Here is the link.

Monastery

When you say “throws an exception”, do you mean “causes a compile error”? – Coiffeur

@Coiffeur Yes, you are right. Sorry for misleading. Thank you, I edited the post. – Monastery

Possible duplicate of Compiler Ambiguous invocation error - anonymous method and method group with Func<> or Action – Lotetgaronne

Answer 1

The reason is that the return type of a method is not part of its signature. Thus, while resolving the correct overload, the compiler only looks at the parameter of the method.

The easiest solution is to simply not use the implicit method group conversion. All of the following compile:

TaskManager.RunSynchronously<MyObject>(
    x => fileMananager.BackupItems(x), package);

TaskManager.RunSynchronously<MyObject>(
    (Action<MyObject>)fileMananager.BackupItems, package);

TaskManager.RunSynchronously<MyObject>(
    new Action<MyObject>(fileMananager.BackupItems), package);

The first one is the most elegant of them, but it also is the only one with a - slight - runtime performance impact, because of an additional redirection. However, this impact is so small that you actually shouldn't care.

Est

Is this valid for all methods or only lambdas? – Dockage

@AlessandroD'Andria: What exactly do you mean? – Est

I didn't realize that. Is there a way how to design my TaskManager.RunSynchronously method so that I would not need explicit conversion? – Monastery

@OndrejJanacek: Right now, I don't see how, sorry. – Est

@DanielHilgarth All right, it is not the subject of this question. But if you ever come across a solution, please update your answer and let me know. By the way, what the magic variable x in the first solution stands for, when the package should be the parameter? – Monastery

@OndrejJanacek: There is no magic variable there. This is a simple lambda expression. When the lambda is called, x will have the value of whatever you pass as the parameter to the lambda. If that's not clear, be sure to read up on lambdas. – Est

Answer 2

Another possible explanation for this nowadays is this:

The code was written for C# version 7.3 (used by default by MSBuild 16.x, corresponding to VS2019), but the build is attempted with an earlier version of C# (which is the default for MSBuild 15.x, corresponding to VS2017).

Earlier versions of C# throw this error, but the overload is resolved correctly in C# 7.3.

Gallinule

Answer 3

I came across the same problem, the solution was:

var r = RunSynchronously<bool>(x =>
{
    return true;
}, true);

RunSynchronously<bool>(x =>
{
}, true);

Now, why the compiler cannot do that???

Laliberte

You can use x => true instead of x => { return true; }. – Gemoets