omochimetaru
@omochimetaru

SwiftにResult型が提案されレビュー入りした

SwiftにResult型が提案され、今日から12日までのレビューが始まった。

提案 https://github.com/apple/swift-evolution/blob/master/proposals/0235-add-result.md

レビュースレッド https://forums.swift.org/t/se-0235-add-result-to-the-standard-library/17752

Result型についてはSwiftフォーラムがメーリングリストだった時代から長いこと話し合いが続いていて、話題もループしがちなため、僕は追いかけるのに疲れてしまって最近は追っていなかったのだが、最近盛り上がっていると思っていたらレビュー入りまでこぎつけていたようで、関わっている人たちの熱意はすごいと思う。

提案されているものは、Result<Value, Error> で、型パラメータが2つある。

おそらく最も使われている antitypical/ResultResult<Value, Error: Swift.Error> とエラーの型に Errorプロトコル制約をかけているが、それが取り除かれている点が興味深い。

これによりエラー型を満たさないケースにも対応できて良い、とされていて、例としてNSURLSessionのAPIが提示されている。

URLSession.shared.dataTask(with: url) { 
  (result: Result<(URLResponse, Data), (Error, URLResponse?)>) in 
    // Type added for illustration purposes.

そして、Resultをthrowsに変換するAPIなど、Errorプロトコル特有の機能は、

extension Result where Error: Swift.Error

の元で追加的に提供されているので、制約がついていない事によるデメリットも無さそうだ。

もう一つ嬉しい点として、

extension Result where Error == Swift.Error

も定義されている。 これはつまり Result<T, Swift.Error> として使用できるということだ。 Swiftのthrowsは検査例外でありつつもエラーの型を明記しないが、そのようなエラーの型を明記しない文脈でResultが使えるということだ。

antitypicalの場合はこれはできず、AnyError型などのType Erasureを他で用意する必要があった。 なぜなら Swift.Error はExistential型で、Existential型はそれ自身のプロトコルには準拠しない、という言語仕様があるからだ。

提案された内容は、このように既存の問題点をうまく解決できているので良さそうだ。 レビュースレッドを見る限り、概ね受け入れられているがAPIの命名への修正提案がチラホラある様子だ。微修正のために棄却され、再提出後のレビューで採用される流れになると予想する。

ところで、Existentialがそれ自身に準拠しない仕様について、Swift実装者の一人であるSlavaが、それを準拠するようにしたら実装がスッキリするし考えてみるべきでは、と言っているのも興味深い。

関連記事

コメントはありません。
omochimetaru
@omochimetaru
フォロー
フォロワー
ブログを開設

クランチで技術ブログを
始めてみませんか?

この先は、クランチへのアカウント登録、及びログインが必要なページになります。

Markdownの書き方
見出し # 見出し(h1)
## 見出し(h2) , ### 見出し(h3) ...
リスト - 箇条書き
   - タブでインデント
番号付きリスト 1. テキスト
2. テキスト
改行 行末に半角スペース2つ
リンクの挿入 [タイトル](https://xxx.com)
引用 > テキスト
コード挿入 ```cpp:title
code
```
画像の挿入 ![代替テキスト](URL "タイトル")
太字 **テキスト**
斜体 *テキスト*
打消し線 ~~テキスト~~
水平線 ***
技術ブログを開設
ログイン