我喜欢使用管道运算符'|>'很多。然而,混合与函数返回“简单”值的函数返回“选项类型的值”,事情就变得有点凌乱,例如当:是一个“可选”管道操作员惯用的F#
// foo: int -> int*int
// bar: int*int -> bool
let f (x: string) = x |> int |> foo |> bar
的作品,但它可能会抛出一个“System.FormatException:。 ..”
现在假设我想解决的是通过使功能‘诠释’给一个可选的结果:
let intOption x =
match System.Int32.TryParse x with
| (true, x) -> Some x
| (false,_) -> None
只有现在的问题是当然的功能
let g x = x |> intOption |> foo |> bar
由于输入错误而无法编译。好吧,简单地定义一个 'optionalized' 管:
let (|=) x f =
match x with
| Some y -> Some (f y)
| None -> None
现在我可以简单地定义:
let f x = x |> intOption |= foo |= bar
,一切都像一个风情万种。
好的,问题:那是否是惯用的F#?是否可以接受?不好的风格?
注:当然,只要有正确的类型“| =”操作符允许分裂,并随意选择合并“管道”,而只关心他们重要的选择:
x |> ...|> divisionOption |= (fun y -> y*y) |=...|>...
我没有看到这方面的需要操作员可以使用'|> Option.map F' - 事实上,您可以定义操作就像那样;) - 并且最好的方法是使用'|> Option.bind f''得到单调情况;) – Carsten
使用管道运算符没有什么特别的“习惯用法”,除了它有时有助于类型推断。滥用它(以及任何其他自定义操作符)可能会大大降低代码的可读性。 – Petr
噢,没想到Option.map。所以我想这回答所有问题;有一个核心库函数,其中我的操作符或多或少是一个特例,因此使用inbuild函数肯定会更好...... thx –