generics - 在什么条件下 unit 是一个类型？

Question

在这被标记为重复之前:我知道这个问题与使用 unit 作为类型参数时有关编译错误的各种问题有关。一些例子:

Why is unit treated differently by the F# type system when used as a generic interface argument?

F# interface inheritance failure due to unit

Using unit as Type Parameter and overriding methods

这些都遇到了与此类似的问题:

type Interface<'a> = 
    abstract member MyFunc : unit -> 'a

let implementingInstance =
  { new Interface<_> with
        member __.MyFunc () = () } // Compiler error!

据我了解，代码无法编译，因为返回单位的函数是用 void 编译的。内部返回，这是 CLI 的一个额外功能，而不是类型。

然而!以下似乎满足编译器:

type RecordVersion<'a> =
  { MyFunc : unit -> 'a }

let recordInstance =
  { MyFunc = ignore }

如果我替换 ignore 这也有效带有 lambda 或 let绑定(bind)模块功能。

对我来说，这只是完全相同事物的另一种表述。 (尽管与 F# 设计指南不一致，后者建议更喜欢接口(interface)而不是带有函数的记录类型。)

我对设计用户指定使用的行为和类型的 API 很感兴趣。因此，我想避免出现意外和令人困惑的编译器错误的情况。但我不太确定该怎么做。看起来 F# 的“功能”函数确实将单元视为一种类型。

这种单位的虚假错误的确切条件是什么？我是否可以通过打破设计指南并使用函数记录而不是接口(interface)来在我的 API 中避免它们？ (我不会介意，但我不确定它是否能永久解决问题。)

Answer 1

我相信规则是静态已知具有返回类型的方法 unit将编译为返回类型为 void 的 .NET 方法在 .NET 类型系统中(静态已知，我的意思是与泛型方法或使用类型参数作为返回类型的泛型类型上的方法相反)。在调用时，编译器隐藏返回 void 的方法之间的区别。和返回 true 的方法 unit CLR 级别的值。

出现示例中的问题是因为正确实现通用接口(interface)实际上需要 unit CLR 级别的返回类型(并且 CLR 确实关心 unit 和 void 之间的区别)。换句话说，当且仅当您想通过静态已知返回 unit 的方法覆盖返回泛型类的类型参数的方法时，才会出现问题。 (基于将 unit 替换为该类型参数)。这里的覆盖，我的意思是要么在类或接口(interface)上实现抽象方法，要么在类上覆盖非密封方法。

正如泰米尔语所指出的，解决此限制的一种方法是确保您使用 F# 函数而不是方法。另一种解决方法是在具有虚拟泛型类型参数的层次结构中引入一个额外的具体类(比如额外的类是 T<'unit> )，并返回 Unchecked.defaultof<'unit>而不是 ()哪里会引起问题。然后你可以派生一个额外的非泛型具体类T来自 T<unit>一切都会好起来的。