我喜歡使用管道運算符'|>'很多。然而,混合與函數返回「簡單」值的函數返回「選項類型的值」,事情就變得有點凌亂,例如當:是一個「可選」管道操作員慣用的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 –