Rust ではなぜ、Either 型ではなく Result 型を採用しているのか
日本語圏の Twitter でたまに揉めている印象。ちょっと気になったので理由を探してみた。
この Reddit に多少答えがありそう。
投稿者いわく、
- Result 型は Option 型と同じように"意味のある可能性"(要するに成功するか失敗するか)を明示できるのでわかりやすい。
- Haskell などにある Either 型は、Left と Right の両方の値を利用できることを明示できるので、中立的だ。
といっている。これはそうだと思う。
Rust used to have both Result and Either, but got rid of the latter because it turned out people basically only ever used Result. So like a lot of times where two ideas both sounded theoretically valid, Rust tried both before making its decision.
- Rust にはかつて
Result
とEither
の両方が存在していたが、Either
は廃止になった。 - 理由は、結局ユーザーが基本的に
Result
しか使用しないことがわかったから。 -
Result
もEither
もどっちも理論的には正しそうなので、一旦両方試してみた。
Isn't that more of an argument that <Entry,VacantEntry> shouldn't be expressed as Result?
たしかに、これは Rust では表現できなそう。VacantEntry
は、書いた人曰くエラーではないので、Result<Entry, VacantEntry>
とするのはおかしい。Option<Entry>
とかしちゃうかも?あるいは、そもそも
enum EntryElem {
Entry,
VacantEntry
}
とできるので、これを使うとか?(ただ、Either
の裏側にある概念を完全に表現できているかと言うと、ちょっとできていないかも)
Either 型をそれでも使いたいケースに対応するためには、Either 型を用意したクレートがあるのでそれが使える。
actix-web には Either
型が用意されている。
4xx 系は確かにサーバー側のエラーではないけれど、実質的に Result::Err に近い形で返したいケースがある。しかもこの情報をできれば一つの型で示したいというコンテクストも含む。このようなケースに Either 型は合致する。