Rust ではなぜ、Either 型ではなく Result 型を採用しているのか
yuki日本語圏の Twitter でたまに揉めている印象。ちょっと気になったので理由を探してみた。
この Reddit に多少答えがありそう。
yuki投稿者いわく、
- Result 型は Option 型と同じように"意味のある可能性"（要するに成功するか失敗するか）を明示できるのでわかりやすい。
- Haskell などにある Either 型は、Left と Right の両方の値を利用できることを明示できるので、中立的だ。
といっている。これはそうだと思う。
yukiRust 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もどっちも理論的には正しそうなので、一旦両方試してみた。
yukiIsn'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 の裏側にある概念を完全に表現できているかと言うと、ちょっとできていないかも）
yukiEither 型をそれでも使いたいケースに対応するためには、Either 型を用意したクレートがあるのでそれが使える。
yukiactix-web には Either 型が用意されている。
4xx 系は確かにサーバー側のエラーではないけれど、実質的に Result::Err に近い形で返したいケースがある。しかもこの情報をできれば一つの型で示したいというコンテクストも含む。このようなケースに Either 型は合致する。