How to explain this "call is ambiguous" error?

Question

The Problem

Consider these two extension methods which are just a simple map from any type T1 to T2, plus an overload to fluently map over Task<T>:

public static class Ext {
    public static T2 Map<T1, T2>(this T1 x, Func<T1, T2> f)
       => f(x);
    public static async Task<T2> Map<T1, T2>(this Task<T1> x, Func<T1, T2> f)
        => (await x).Map(f);
}

Now, when I use the second overload with a mapping to a reference type...

var a = Task
    .FromResult("foo")
    .Map(x => $"hello {x}"); // ERROR

var b = Task
    .FromResult(1)
    .Map(x => x.ToString()); // ERROR

...I get the following error:

CS0121: The call is ambiguous between the following methods or properties: 'Ext.Map(T1, Func)' and 'Ext.Map(Task, Func)'

Mapping to a value type works fine:

var c = Task
    .FromResult(1)
    .Map(x => x + 1); // works

var d = Task
    .FromResult("foo")
    .Map(x => x.Length); // works

But only as long the mapping actually uses the input to produce an output:

var e = Task
    .FromResult(1)
    .Map(_ => 0); // ERROR

The Question

Can anyone please explain to me what is going on here? I've already given up on finding a feasible fix for this error, but at least I'd like to understand the root cause of this mess.

Additional Notes

So far I found three workarounds which are unfortunately not acceptable in my use case. The first is to specify the type arguments of Task<T1>.Map<T1,T2>() explicitly:

var f = Task
    .FromResult("foo")
    .Map<string, string>(x => $"hello {x}"); // works

var g = Task
    .FromResult(1)
    .Map<int, int>(_ => 0); // works

Another workaround is to not use lambdas:

string foo(string x) => $"hello {x}";
var h = Task
    .FromResult("foo")
    .Map(foo); // works

And the third option is to restrict the mappings to endofunctions (i.e. Func<T, T>):

public static class Ext2 {
    public static T Map2<T>(this T x, Func<T, T> f)
        => f(x);
    public static async Task<T> Map2<T>(this Task<T> x, Func<T, T> f)
        => (await x).Map2(f);
}

I created a .NET Fiddle where you can try out all the above examples yourself.

Answer 1

According to C# Specification, Method invocations, the next rules are used to consider a generic method F as a candidate for method invocation:

• Method has the same number of method type parameters as were supplied in the type argument list,

  and

• Once the type arguments are substituted for the corresponding method type parameters, all constructed types in the parameter list of F satisfy their constraints (Satisfying constraints), and the parameter list of F is applicable with respect to A (Applicable function member). A - optional argument list.

For expression

Task.FromResult("foo").Map(x => $"hello {x}");

both methods

public static T2 Map<T1, T2>(this T1 x, Func<T1, T2> f);
public static async Task<T2> Map<T1, T2>(this Task<T1> x, Func<T1, T2> f);

satisfy these requirements:

• they both have two type parameters;

• their constructed variants

  // T2 Map<T1, T2>(this T1 x, Func<T1, T2> f)
  string       Ext.Map<Task<string>, string>(Task<string>, Func<Task<string>, string>);
  
  // Task<T2> Map<T1, T2>(this Task<T1> x, Func<T1, T2> f)
  Task<string> Ext.Map<string, string>(Task<string>, Func<string, string>);
  

satisfy type constraints (because there is no type constraints for Map methods) and applicable according to optional arguments (because also there is no optional arguments for Map methods). Note: to define the type of the second argument (lambda expression) a type inference is used.

So at this step the algorithm considers both variants as candidates for method invocation. For this case it uses Overload resolution to determine which candidate better fits for invocation. Words from specification:

The best method of the set of candidate methods is identified using the overload resolution rules of Overload resolution. If a single best method cannot be identified, the method invocation is ambiguous, and a binding time error occurs. When performing overload resolution, the parameters of a generic method are considered after substituting the type arguments (supplied or inferred) for the corresponding method type parameters.

Expression

// I intentionally wrote it as static method invocation.
Ext.Map(Task.FromResult("foo"), x => $"hello {x}");

can be rewritten the next way using constructed variants of the method Map:

Ext.Map<Task<string>, string>(Task.FromResult("foo"), (Task<string> x) => $"hello {x}");
Ext.Map<string, string>(Task.FromResult("foo"), (string x) => $"hello {x}");

Overload resolution uses Better function member algorithm to define which of this two methods better fits method invocation.

I have read this algorithm several times and haven't found a place where the algorigthm can define the method Exp.Map<T1, T2>(Task<T1>, Func<T1, T2>) as better method for considered method invocation. In this case (when better method cannot be defined) a compile time error occures.

To sum up:

• method invocation algorithm considers both methods as candidates;
• better function member algorithm cannot define better method to invoke.

---

Another approach of helping compiler to choose better method (as you did in your other workarounds):

// Call to: T2 Map<T1, T2>(this T1 x, Func<T1, T2> f);
var a = Task.FromResult("foo").Map( (string x) => $"hello {x}" );

// Call to: async Task<T2> Map<T1, T2>(this Task<T1> x, Func<T1, T2> f);
var b = Task.FromResult(1).Map( (Task<int> x) => x.ToString() );

Now the first type argument T1 is explicitly defined and an ambiguity does not occur.

Answer 2

In overload resolution, the compiler will infer type arguments if not specified.

In all the error cases, the input type T1 in Fun<T1, T2> is ambiguous. For example:

Both Task<int>, and int have ToString method, so there is no way to infer whether it is task or int.

However if + is used in expression, it is clear that the input type is integer because task does not support + operator. .Length is the same story.

This can also explain other errors.

UPDATE

The reason for passing Task<T1> won't make the compiler pick up the method with Task<T1> in argument list is the compiler needs to take effort to infer T1 out of Task<T1> because T1 is not directly in the method's argument list.

Possible fix: Make Func<> to use what is existing in the method's argument list, so the compiler takes less effort when inferring T1.

static class Extensions
{
    public static T2 Map<T1, T2>(this T1 obj, Func<T1, T2> func)
    {
        return func(obj);
    }

    public static T2 Map<T1, T2>(this Task<T1> obj, Func<Task<T1>, T2> func)
    {
        return func(obj);
    }
}

Usage:

// This calls Func<T1, T2>
1.Map(x => x + 1);

// This calls Func<Task<T1>, T2>
Task.FromResult(1).Map(async _=> (await _).ToString())

// This calls Func<Task<T1>, T2>
Task.FromResult(1).Map(_=> 1)

// This calls Func<Task<T1>, T2>.
// Cannot compile because Task<int> does not have operator '+'. Good indication.
Task.FromResult(1).Map(x => x + 1)

Answer 3

add braces

var result = (await Task
            .FromResult<string?>("test"))
            .Map(x => $"result: {x}");

your FilterExt async method is just adding braces to (await x) and then calls the non async method, so what for do you need async method??

UPDATE: As i noticed in many .net libraries, developers just adding Async suffix to async methods. You can name method MapAsync, FilterAsync