Improve type inference with generic interfaces that themselves are used as generic type constraints

[fitdev]

Version Used: 3.0.19.12206 (VS 2019 RC1)

Motivation

Nowadays in order to avoid boxing of a value type that is "viewed" through an interface one has to use generic constraints as illustrated below. This approach works fine when the interface is non-generic.

However as soon as the interface itself becomes generic, the approach below is no longer as useful from the programming convenience point of view. The introduction of the 2nd generic type parameter (TInterface being 1st, and T in SomeInterface<T> being second) prevents type inference from correctly inferring all types as illustrated in the example below, causing one to specify both generic type parameters at every call site!

This seems to be completely unnecessary, as in the example below the var xr1 = new Range<double> clearly contains all the information needed for the type inference to work: the Intersects method requires type TRange to be something that implements IRange<T> interface. Well' that's just Range struct. And then the T must be implementing IComparable<T>. In the example it's double, which indeed satisfies the type constraints. So, all the information needed by the compiler to infer types correctly seems to be present.

Steps to Reproduce:

	public interface IRange<T> where T : IComparable<T> {
		T From { get; }
		T To { get; }
	}

	public readonly struct Range<T> : IRange<T> where T : IComparable<T>
		public T From { get; }
		public T To { get; }
		public Range(T from, T to) {
			From = from;
			To = to;
		}    
	}

	public static class Extensions {
		// To avoid boxing when TRange is a struct, the approach below:
		public static bool Intersects<TRange, T>(this TRange it, TRange other) where TRange : IRange<T> where T : IComparable<T> => it.From.CompareTo(other.To) < 1 && it.To.CompareTo(other.From) >= 0;
		// ... is preferred over this:
		public static bool IntersectsWithBoxing<T>(this IRange<T> it, IRange<T> other) where T : IComparable<T> => it.From.CompareTo(other.To) < 1 && it.To.CompareTo(other.From) >= 0;
	}

	public static class Program {
		public static void Main() {
			var xr1 = new Range<double>(1.0, 3.0);
			var xr2 = new Range<double>(2.0, 3.7);

			if (xr1.Intersects(xr2)) {  // <- CS0411: The type arguments for method 'Extensions.Intersects<TRange, T>(TRange, TRange)' cannot be inferred from the usage. Try specifying the type arguments explicitly.
				//...
			}
			if (xr1.Intersects<Range<double>, double>(xr2)) { // <- What you have to do now.
				//...
			}
		}
	}

Expected Behavior:

No need to manually specify generic type parameters at every call site. Types should be inferred.

Actual Behavior:

Compiler complains: CS0411: The type arguments for method cannot be inferred from the usage. Try specifying the type arguments explicitly.

[CyrusNajmabadi]

This appears to be a language change request. As such, it should go in: dotnet/csharplang.

[BenMakesGames]

this comes up from time to time for me as well, especially when doing "handler"-type logic.

for example, given the following method:

public TResponse Dispatch<TRequest, TResponse>(TRequest request)
        where TRequest: IRequest<TResponse> // TRequest implies a TResponse
{
    ...
}

as a caller of Dispatch, I expect the following to work:

var request = new SomeRequest(); // assuming SomeRequest: IRequest<SomeResponse>

dispatcher.Dispatch(request);

the above code will not compile; the last line gets the error "The type arguments [...] cannot be inferred from the usage. Try specifying the type arguments explicitly." but it feels like the type arguments could be unambiguously inferred by the compiler.

the above might be achieved "for free" by adding smarter type inference to the underlying types. for example:

public interface IRequest<TResponse> { }

// currently, the following will not compile; we must write IHandler<TRequest, TResponse>
// however, it feels like TResponse can be inferred from the constraint on TRequest
public interface IHandler<TRequest>
    where TRequest : IRequest<TResponse>
{
    TResponse Handle(TRequest request);
}


public class DispatchService
{
    // again, the following will not compile; Dispatch<TRequest, TResponse> is expected,
    // and again, it feels like TResponse could be inferred
    public TResponse Dispatch<TRequest>(TRequest request)
        where TRequest: IRequest<TResponse>
    {
        var handler = GetTheHandlerSomehow<TRequest>();

        return handler.Handle(request);
    }
}

if C# was able to infer the types and compile that code, then calls to Dispatch without specifying either type will "just work".

the following issues/discussions seem similarish, seeking to decrease friction when using generics:

• Champion: "Partial Type Inference" #1349
• Proposal: Allow partial generic specification #1348
• Type argument inference with unambiguous method group #129

[yuyang9119]

Perhaps it can be designed in this way, placing the necessary generic types on the left and the optional ones on the right. When used, specifying all necessary generic arguments from left to right should be enough.

interface IAdapter<TValue> { ... }
T Func<TAdapter, TValue>() where TAdapter : IAdapter<TValue> { ... }

// Use
class IntAdapter : IAdapter<int> { ... }
class GenericAdapter<T> : IAdapter<T> { ... }
int intValue = Func<IntAdapter>();
string stringValue = Func<GenericAdapter<string>>();

IDEs can prompt designers to place necessary generic types on the left and also remind users to omit unnecessary generic type arguments.