为什么 Func<...> 和 Action 不统一？

Question

例如，我发现自己一直想传递带有返回且没有输入的 Func 来代替 Action

Func<int> DoSomething = ...;

Task.Run(DoSomething);

哪里，我并不关心DoSomething的返回值。

然而，这些类型并没有统一，我最终将调用包装起来

Task.Run(() => { DoSomething(); });

有没有办法让这些类型统一而不用包装？另外，它们不统一是否有很好的设计原因？

Answer 1

从CLI Standard拉取：

II.4.6.1 委托签名兼容性

委托只能可验证地绑定到目标方法，其中：

1. 目标方法的签名是delegate-assignable-to委托的签名；

...

T 类型的目标方法或委托是delegate-assignable-to当且仅当以下所有条件都适用时：

4. T的返回类型U和D的返回类型V，V是assignable-toU。

Answer 2

您希望以下陈述为真：

如果我有Func<T>，我应该可以在需要Action 的地方使用它。

这要求Func<T> 是(A) 可分配给Action 或(B) 可隐式转换为Action。

如果我们假设 (A) 需要T，它可以是任何类型，可分配给void。

Eric Lippert 在his blog 中回答了这个问题：

出于从方法组到委托类型的协变返回类型转换的目的，“void”是否应该被视为所有可能类型的超类型？

他的回答是“不”，因为这最终与 CLI 规范不兼容。 CLI 规范要求返回值进入堆栈，因此void 函数最终不会生成“pop”指令，而那些确实返回某些内容的函数会生成“pop”指令。如果有某种方法可以让“动作”包含void 函数或返回某些内容的函数，这在编译时是未知的，编译器将不知道是否生成“pop” "指令。

他接着说：

如果 CLI 规范规定“任何函数的返回值都在‘虚拟寄存器’中传回”，而不是将其压入堆栈，那么我们可以使返回 void 的委托与返回任何内容的函数兼容。您总是可以忽略寄存器中的值。但这不是 CLI 指定的，所以我们不能这样做。

换句话说，如果存在存储函数返回值的“虚拟寄存器”（可能在 CLI 规范中不存在），C# 的编写者及其编译器可能已经完成了您想要的操作，但是他们不能，因为他们不能偏离 CLI 规范。

如果我们假设 (B)，就会发生重大变化，正如 Eric Lippert 在 this blog 中解释的那样。将他博客中的示例改编为这个，如果从Func<T> 到Action 的隐式转换，一些程序将不再编译过去（重大更改）。该程序当前可以编译，但尝试取消注释隐式转换运算符，类似于您所要求的，它不会编译。

public class FutureAction
{
    public FutureAction(FutureAction action)
    {
    }

    //public static implicit operator FutureAction(Func<int> f)
    //{
    //    return new FutureAction(null);
    //}

    public static void OverloadedMethod(Func<FutureAction, FutureAction> a)
    {
    }

    public static void OverloadedMethod(Func<Func<int>, FutureAction> a)
    {
    }

    public static void UserCode()
    {
        OverloadedMethod(a => new FutureAction(a));
    }
}

（显然，这不是他们要做的，因为这只适用于Func<int> 而不是Func<T>，但它说明了问题。）

总结

我认为您面临的问题是 CLI 规范的产物，当时可能没有预见到，我猜他们不想引入重大更改以允许隐式转换为工作。