c# - 为什么类型推断在此代码中不起作用？

Question

假设我有一个如下所示的服务接口(interface):

public interface IFooService
{
    FooResponse Foo(FooRequest request);
}

在调用此类服务​​的方法时，我想解决一些横切问题；例如，我想要统一的请求日志记录、性能日志记录和错误处理。我的方法是使用一个带有 Invoke 方法的通用基“Repository”类，该方法负责调用该方法并围绕它做其他事情。我的基类看起来像这样:

public class RepositoryBase<TService>
{
    private Func<TService> serviceFactory;

    public RepositoryBase(Func<TService> serviceFactory)
    {
        this.serviceFactory = serviceFactory;
    }

    public TResponse Invoke<TRequest, TResponse>(
        Func<TService, Func<TRequest, TResponse>> methodExpr,
        TRequest request)
    {
        // Do cross-cutting code

        var service = this.serviceFactory();
        var method = methodExpr(service);
        return method(request);
    }
}

这很好用。然而，我使代码更简洁的整个目标因类型推断未按预期工作这一事实而受阻。例如，如果我写这样的方法:

public class FooRepository : BaseRepository<IFooService>
{
    // ...

    public BarResponse CallFoo(...)
    {
        FooRequest request = ...;
        var response = this.Invoke(svc => svc.Foo, request);
        return response;
    }
}

我得到这个编译错误:

The type arguments for method ... cannot be inferred from the usage. Try specifying the type arguments explicitly.

显然，我可以通过将调用更改为:

var response = this.Invoke<FooRequest, FooResponse>(svc => svc.Foo, request);

但我想避免这种情况。有没有办法重新编写代码以便我可以利用类型推断？

编辑:

我还应该提一下，早期的方法是使用扩展方法；此工作的类型推断:

public static class ServiceExtensions
{
    public static TResponse Invoke<TRequest, TResponse>(
        this IService service, 
        Func<TRequest, TResponse> method, 
        TRequest request)
    {
        // Do other stuff
        return method(request);
    }
}

public class Foo
{
    public void SomeMethod()
    {
        IService svc = ...;
        FooRequest request = ...;
        svc.Invoke(svc.Foo, request);
    }
}

Answer 1

您问题的标题是“为什么类型推断在此代码中不起作用？”让我们简单地讨论有问题的代码。场景是其核心:

class Bar { }

interface I
{
    int Foo(Bar bar);
}

class C
{
    public static R M<A, R>(A a, Func<I, Func<A, R>> f) 
    { 
        return default(R); 
    }
}

调用站点是

C.M(new Bar(), s => s.Foo);

我们必须确定两个事实:A 是什么？和 R ？我们必须继续了解哪些信息？那new Bar()对应A和 s=>s.Foo对应Func<I, Func<A, R>> .

显然我们可以确定 A必须是 Bar从第一个事实。显然我们可以确定 s必须是 I .所以我们现在知道 (I s)=>s.Foo对应Func<I, Func<Bar, R>> .

现在的问题是:我们能否推断出 R是int通过对 s.Foo 进行重载解析在 lambda 的主体中？

遗憾的是，答案是否定的。你和我可以做那个推理，但编译器不能。当我们设计类型推断算法时，我们考虑过添加这种“多级”lambda/委托(delegate)/方法组推断，但认为这样做的成本太高，无法带来好处。

对不起，你运气不好；通常，C# 方法类型推断中不会进行需要“挖掘”不止一层的函数抽象的推断。

Why did this work when using extension methods, then?

因为扩展方法没有超过一层的功能抽象。扩展方法案例为:

class C
{
    public static R M<A, R>(I i, A a, Func<A, R> f) { ... }
}

调用站点

I i = whatever;
C.M(i, new Bar(), i.Foo);

现在我们有什么信息？我们推断 A是Bar像以前一样。现在我们必须推断出什么 R知道i.Foo映射到 Func<Bar, R> .这是一个简单的重载解决问题；我们假装有人调用i.Foo(Bar)并让重载决议完成它的工作。过载解析返回并说 i.Foo(Bar)返回 int , 所以 R是int .

请注意，这种涉及方法组的推理原本打算添加到 C# 3 中，但我搞砸了，我们没有及时完成。我们最终将这种推断添加到 C# 4。

另请注意，要使这种推断成功，必须已经推断出所有参数类型。我们必须只推断返回类型，因为为了知道返回类型，我们必须能够进行重载解析，而要进行重载解析，我们必须知道所有参数类型。我们不会做任何诸如“哦，方法组中只有一个方法，所以让我们跳过重载决议，让那个方法自动获胜”之类的废话。