How to explain this "call is ambiguous" error?

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.

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)