Type Argument Inference Fails if the same Type Parametrized Callable is used Multiple Times

[ScottCarda-MS]

This code highlights an issue with type argument inference:

operation` Foo<'T> (arg : 'T) : Unit { }
 
operation DoTwo<'A, 'B>(op1 : ('A => Unit), arg1 : 'A, op2: ('B => Unit), arg2 : 'B) : Unit {
    op1(arg1);
    op2(arg2);
}
 
operation CombineTwo<'A, 'B>(op1 : ('A => Unit), op2: ('B => Unit)) : (('A, 'B) => Unit) {
    return DoTwo(op1, _, op2, _);
}
 
operation Main() : Unit {
    (CombineTwo(Foo, Foo))("Hi", 3);
}

The expression in the Main operation has an issue here. The type parameter resolution data structure in the syntax tree doesn't explicitly contain any way of keeping track of which instance of a type parameter the resolution is for. It only contains the callable name, the type parameter name, and the resolving type. In the code above, in Main, the expression has two conflicting resolutions because it is trying to resolve Foo.T to String and its trying to resolve Foo.T to Int. It sees this conflict because it can't differentiate between the resolution for the first Foo and the resolution for the second Foo. As a result it throws an error complaining about ambiguity.

However if we instead have two different functions passed into CombineTwo:

operation Bar<'T> (arg : 'T) : Unit { }

operation Main() : Unit {
    (CombineTwo(Foo, Bar))("Hi", 3);
}

Now there is no more conflict because it sees Foo.T resolving to String and Bar.T resolving to Int. The fact that one of these scenarios is supported and not the other is the issue.

[ScottCarda-MS]

I have been looking into how C# handles similar cases and found that they have a rule that protects against this. They don't allow type arguments to be inferred from how the method's return is used. This would actually prevent both of these cases from compiling, which is at least consistent, because in both cases the type parameters don't get resolved until the ("Hi", 3) is applied to the returned operation of CombineTwo. While I think it would be neat if we could handle both cases, I think preventing type argument inference by use of the return makes sense and would be consistent with out rule against capturing unresolved generics.

I think it would make type parameters much easier to work with in the QDK if they were about to point to specific instances, and that might let us be a lot more permissive with what we can handle, such as capturing unresolved generics. However, getting there may be more trouble than its worth, and preventing type inference based on return values seems reasonable and much more doable.

One thing that I'm not sure on is how, if at all, the ability to use partial applications affect the design decision to prevent type argument inference on return value.

[ScottCarda-MS]

We don't know when we might be able to pick this up, but we believe we may be able to support this scenario.