antitypical/Resultについて

Question

antitypical/Resultの型パラメータがなぜそのようになっているのか疑問に思ったので質問します。

antitypical/Resultでは Resultの定義は以下のようになっています。（必要部分のみ抜き出し）

enum Result<Value, Error: Swift.Error> { ... }

---

疑問に思ったのは以下の2点です。

######1. なぜ以下の定義ではないのか
~~enum Result<Value, Error> { … }~~~
Error: Swift.Errorとせずとも単にErrorとするだけで全く同じことになると思うのですが、
なぜError: Swift.Errorとしているのでしょか？

######2.そもそもErrorを型パラメータにする必要があるのか
Swiftの場合はErrorが既に定義されているので

enum Result<Value> { ... }

としても同等の事が実装出来ると思います。なぜErrorを型パラメータに含めているのでしょ。
こちらに関してはSwift以外の実装に合わせたのではないか、使用時にエラーの型を明示/限定できるようにではないか、とは思っていますが、ほかの理由があるのかが知りたいです。

以上、よろしくお願いします

---

追記

Swiftには標準でErrorという型があります。
そのため
~~
enum Result<Value, Error: Swift.Error> { // ErrorはSwift.Errorに制限される。
case value(Value)
case error(Error)
}
~~
としても
~~
enum Result<Value, Error> { // ErrorはSwift.Errorそのもの。
case value(Value)
case error(Error)
}
~~
としてもほとんど違いはなく、また

enum Result<Value> {
    case value(Value)
    case error(Error)  // 型パラメータを持たずともError型を持てる
}

としてもerrorは表現可能です。

Answer 1

２の質問からお答えします。

そもそもErrorを型パラメータにする必要があるのか

これは関数型言語ならではのものでEither型というものです。
このワードでググルとたくさんの説明が出ると思います。

自分なりに説明すると、エラーとの戦い方の一つの選択肢です。

以下にエラー処理の手法と問題点をあげます

例外にしてそれをキャッチして処理するというやり方

Javaが採用している方法です。どこがエラー処理を行うかコードから読み取りづらいという問題を抱えています。
よく見ると思うので特に例は示しません

多値を返すやり方

Goが採用している点です。
上記Javaと違って必ずエラーハンドリングをしないといけないという状況になります。
それがメリットであり必ずエラーハンドリングをしないといけないのでどこがエラー処理をしているか追いやすいのです。

func something() (int, error) {
   if err := hogehoge(); err != nil {
       return -1,err
   }
   return 42, nil
}

これの問題点はメソッドチェーンが作れないということです。
つまり返り値のメソッドを再度呼び出して処理を継続することができないのです。
必ずエラーを処理してから次のメソッドを呼び出すという縛りができます。

Eitherのやり方

おわかリでしょうか。上記２つの例のいいとこ取りしたのがResult<Value, Error>なのです。
エラー情報を含んだ一つの塊を返すのでメソッドチェーンで拾って次の処理に使ってもいいですし
そもそもエラーを含んでいるからメソッドチェーンの処理を中断してもいいです。

１の質問について

enum Result<Value, Error: Swift.Error> { ... }

なのは単にSwift.Errorを継承したError型に限定したいんでしょう。
エラーがSwift.Errorであることが保証できれば、エラー処理の時に必ず存在するメソッドかあるというメリットがあります

Comments

[MasakiHori]

SwiftでResultを表現する方法を追記しました。

Swiftには標準でErrorという型（protocol）が存在しています。（Javaで言うところのInterfaceのようなものです）
Errorはprotocolですので実態はなく、使用者がErrorに準拠（継承）した実体を定義する必要がある。

その上で
1, わざわざSwift.Errorに準拠した新しいErrorを型パラメータとして持つ必要があるのか。
2, そもそもError自体を型パラメータとして持つ必要があるのか。
という質問です。

[MasakiHori]

色々書いてたら1番目の問題は僕の勘違いであることがわかりましたので取り下げました。

[m0a]

Result<Value> にしてしまうとその内部で使っているSwift.Errorに固定されてしまうことになります。
そこをMyErrorなどとして任意のメソッドを追加した自作のErrorを用意すれば
全体を通してMyErrorが使えることになります。
一々アップキャストして使いたくないですよね。

[MasakiHori]

なるほどです。　理解できました。　ありがとうございます。