为何F# SRTP中的OR活动模式被解析为AND模式？

问题现象 #

在SRTP（静态解析类型参数）场景下，定义的OR活动模式(|PropAOrB|)未能实现预期逻辑——本该接受仅包含PropA或PropB属性的类型，但实际编译时要求输入类型同时拥有两个属性。调用仅含单个属性的匿名类型时，会触发如下编译错误：

• "类型'{| PropA: 'a |}'不支持运算符'get_PropB'"
• "类型'{| PropB: 'a |}'不支持运算符'get_PropA'"

原因分析 #

F#的inline函数与活动模式采用静态解析，编译时会合并OR活动模式所有分支的SRTP约束。原代码中(|PropAOrB|)的两个分支分别依赖PropA和PropB的成员约束，编译器会强制要求输入类型同时满足这两个约束，导致OR模式被当成AND模式处理。从生成的C#代码也能看到，|PropAOrB|$W方法同时接收了get_PropA和get_PropB两个委托，证明编译器要求类型必须同时具备两个属性。

解决方案 #

要实现真正的“二选一”逻辑，需避免将多个SRTP约束合并到单个complete活动模式中，可采用以下两种方式：

方案1：直接在函数参数中使用OR分支 #

无需定义合并的OR活动模式，直接在doThingsWithOrProps的参数匹配中写OR分支：

let inline (|PropA|) source =
    (^Source: (member PropA: 'PropA) source)

let inline (|PropB|) source =
    (^Source: (member PropB: 'PropB) source)

let inline doThingsWithOrProps (PropA p | PropB p) =
    printfn $"{nameof p} = %A{p}"

// 现在可以正常编译运行
doThingsWithOrProps {| PropA = "wer" |}
doThingsWithOrProps {| PropB = "wer" |}

这种方式下，编译器会分别处理两个分支的SRTP约束，只要输入类型满足其中一个分支的成员要求即可通过编译。

方案2：使用Partial活动模式（用于逻辑复用） #

如果需要在多个地方复用“拥有PropA或PropB”的匹配逻辑，可以定义partial活动模式（返回option类型）：

let inline (|PropA|) source =
    (^Source: (member PropA: 'PropA) source)

let inline (|PropB|) source =
    (^Source: (member PropB: 'PropB) source)

let inline (|PropAOrB|_|) source =
    match source with
    | PropA p -> Some p
    | PropB p -> Some p
    | _ -> None

let inline doThingsWithOrProps (PropAOrB propAOrB) =
    printfn $"{nameof propAOrB} = %A{propAOrB}"

// 测试调用正常
doThingsWithOrProps {| PropA = "testA" |}
doThingsWithOrProps {| PropB = "testB" |}

Partial活动模式通过option类型处理匹配成功/失败的情况，编译器会为每个分支单独解析SRTP约束，不会强制合并所有要求。

关键总结 #

• Complete活动模式（返回非option类型）在SRTP场景下会合并所有分支的约束，导致OR逻辑失效；
• Partial活动模式或直接在函数中写OR分支，会让编译器分别处理每个分支的约束，实现预期的“二选一”逻辑。

内容的提问来源于stack exchange，提问作者Natalie Perret