为什么 None 表示为 null？

Question

CompilationRepresentationFlags.UseNullAsTrueValue可以用来

允许在可区分联合中使用 null 作为 null 鉴别器的表示

Option.None 是这方面最突出的例子。

为什么这很有用？与传统的联合案例检查机制（生成的Tag 属性）相比，空值检查有何优势？

这可能会导致意想不到的行为：

Some(1).ToString() //"Some(1)"
None.ToString()    //NullReferenceException

编辑

我测试了 Jack 的断言，即与 null 而不是静态只读字段相比更快。

[<CompilationRepresentation(CompilationRepresentationFlags.UseNullAsTrueValue)>]
type T<'T> =
  | Z
  | X of 'T

let t = Z

使用 ILSpy，我可以看到 t 编译为 null（如预期的那样）：

public static Test.T<a> t<a>()
{
    return null;
}

测试：

let mutable i = 0
for _ in 1 .. 10000000 do
  match t with
  | Z -> i <- i + 1
  | _ -> ()

结果：

真实：00:00:00.036，CPU：00:00:00.046，GC gen0：0，gen1：0，gen2：0

如果CompilationRepresentation 属性被移除，t 将成为静态只读字段：

public static Test.T<a> t<a>()
{
    return Test.T<a>.Z;
}

public static Test.T<T> Z
{
    [CompilationMapping(SourceConstructFlags.UnionCase, 0)]
    get
    {
        return Test.T<T>._unique_Z;
    }
}

internal static readonly Test.T<T> _unique_Z = new Test.T<T>._Z();

而且结果是一样的：

真实：00:00:00.036，CPU：00:00:00.031，GC gen0：0，gen1：0，gen2：0

模式匹配在前一种情况下编译为t == null，在后一种情况下编译为t is Z。

Answer 1

Jack 的回答似乎不错，但稍微扩展一下，在 IL 级别，CLR 提供了用于加载空值 (ldnull) 的特定操作码和测试它们的有效方法（ldnull 后跟 beq /bne.un/ceq/cgt.un)。当 JITted 时，这些应该比取消引用 Tag 属性并相应地分支更有效。虽然每次调用的节省可能很小，但选项类型的使用频率足够高，累积的节省可能很可观。

当然，正如您注意到的那样，有一个权衡：从obj 继承的方法可能会抛出空引用异常。这是在处理 F# 值时使用 string x/hash x/x=y 而不是 x.ToString()/x.GetHashCode()/x.Equals(y) 的一个很好的理由。遗憾的是，null 表示的值没有（可能的）等效于 x.GetType()。

Answer 2

F# 编译器有时使用 null 作为 None 的表示，因为它比实际创建 FSharpOption 的实例并检查 Tag 属性更有效。

想一想——如果你有一个不允许为空的普通 F# 类型（如记录），那么任何指向该类型实例的指针（CLR 内部使用的指针）永远不会是 @987654323 @。同时，如果T是可以表示n状态的类型，那么T option可以表示n+1状态。因此，使用null 作为 None 的表示只是利用了一个额外的状态值，这是由于 F# 类型不允许为空而可用。

如果您想尝试关闭此行为（对于普通 F# 类型），您可以将[<AllowNullLiteral(true)>] 应用于它们。