Rust での unwrap, expect, panic, assert 周辺の話

Ryusei @mandel59

「panic は回復不可能なエラーを意味する」。それはそう。じゃあ、回復不可能なエラーでない、ただのエラーだったり、未実装な機能を使おうとしただけだったりするなら、それは（panicで表現することもできるけど）panicで表現するべきじゃないよね、そういうことを私は言っています。

らりお・ザ・.*🈗然㊌㋞㋰㋷㋓ @lo48576

はい。ただのエラーだったり未実装だったりは panic で表現するべきでないと思います。 (unimplemented!() や todo!() が production code に表れるべきでないという clippy lint はその思想によるもののはずなので)

電波猫 @dempacat

panicは結構気軽に使ってしまう。Vecでアロケーションミスったときpanicするのやめろ、という議論はどっかにあった気がする。

Ryusei @mandel59

Rust使いたいってことは極力型システムを使い倒したい人な気がするんだけど

らりお・ザ・.*🈗然㊌㋞㋰㋷㋓ @lo48576

ただし、「仕様として許されていない利用方法 (理屈の上では回復可能) が発生したとき」の扱いについて私の考えは違っていて、「利用先ライブラリの仕様に従えなかった時点で、利用元 (ユーザコード) もまた暗黙に仕様違反している」という認識なので、それは panic でいいんじゃない？という考え

トデス子'\ @todesking

みんな仕様を表現できるほどリッチな型システム使ってないのでは???

らりお・ザ・.*🈗然㊌㋞㋰㋷㋓ @lo48576

「ライブラリを利用するとき、利用先ライブラリの仕様や制約を遵守する」というのはユーザコードの暗黙の仕様として当然存在していると考えて良いと思うんですよね。 逆に言えば、仕様違反の方法でライブラリを利用するようなコードは実装時点から既に壊れていて、それは実行時に「回復可能」ではない

Ryusei @mandel59

あー、まあそうだよね 範囲外アクセスとか、そういうのはそうだよね

電波猫 @dempacat

panicするかしないかも含めて、仕様の一部だと捉えている。仕様策定の指針として、復帰可能なものは極力panicせずエラーを返せ、というのはあるし、そうすべきだが、復帰可能と捉えるか否かは、実際に復帰可能かどうかではなく、仕様を作る人の判断になるかと。

らりお・ザ・.*🈗然㊌㋞㋰㋷㋓ @lo48576

厳密な意味では「回復可能」かもしれないけど、壊れたコードが自身が壊れているか否かを正しく判断できるという想定はだいぶナンセンスな気がします。そんな判断コードがあるくらいなら実装を修正しろという話なので。

Ryusei @mandel59

いや自分も仕様を完全に型システムで表現するべきだという主張をしているわけじゃなくて、無理のない範囲で表現して表現できない部分はpanicでぜんぜんいいと思うしそう言っているんですが

KOBA789 @KOBA789

定義域がドキュメントに書いてあるなら定義域外の引数には全部 panic で返していい

電波猫 @dempacat

仕様を作る人の判断に「なる」というのは、無知ゆえになってしまうという意味(だけ)ではなく、「できる場合もあるにはあるかもしれないし、ユースケースもあるにはあるかもしれないけれど、それは考えない」という判断もあってもよい、という意味。

denjiry @denjiry

panic系列も別の型にして特別扱いするとかするのよさそう？

Ryusei @mandel59

どの程度まで型で表現してどこからが無理かってのが人によって感覚が違っているから、そこで判断は分かれると思います……

らりお・ザ・.*🈗然㊌㋞㋰㋷㋓ @lo48576

暗黙の nullability では飽き足らず暗黙の crashability なる概念が (?)

Ryusei @mandel59

たとえば配列の範囲外アクセスエラーとかも、配列を添え字でアクセスしようとするから発生するわけで、エラーが起こらないインターフェースを使うのがそもそも望ましいですよね

らりお・ザ・.*🈗然㊌㋞㋰㋷㋓ @lo48576

まあ真面目な話をすると、それって本来はエラーの有無や例外の有無に近い方法で表現されていた気がしていて、なんか同じことを二重に抽象化している気がする

Ryusei @mandel59

（Rustのunsafeは使い方が決まっているというか、panicを起こすだけならunsafeではないですけど、panicが起きうる関数も極力分かるようになっていてほしい……）

denjiry @denjiry

indexをなくしてget系列にするべきなのは賛成できる(Elmもそう)

Ryusei @mandel59

型システムで完全性を保証できないからpanicがあるわけで、panicが起きるかどうかを型システムで知ることはできないわけですが

KOBA789 @KOBA789

うまく型パズルすればパニックが起きないように組める場合でも、変更のしやすさとかの観点から実行時に panic するように書くことはある(実装がバグってない限りは panic することはないが)

らりお・ザ・.*🈗然㊌㋞㋰㋷㋓ @lo48576

panic の有無、型レベルでどう表現されるべきかピンとこない。 一応 RFC 1574 で「パニックしうるなら Panics セクションをドキュメントに用意しようね」とは言われているが、これは仕様上明示される panic。 1574-more-api-documentation-conventions - The Rust RFC Book rust-lang.github.io/rfcs/1574-more…

らりお・ザ・.*🈗然㊌㋞㋰㋷㋓ @lo48576

「内部的なバグの検知としての、本来起きえない panic」が起きるかどうかをドキュメントや型で明示するというのは……うーん そもそも起きえないものなので明示してもしゃーない気はする。 関数に「未知のバグがある可能性があります」と但し書きするくらいにナンセンスな感じ。

Ryusei @mandel59

型で表現できないからpanicがある 絶対にpanicを起こして値を返さない場合は ! で表現する panicを起こすかもしれない、ということを型で表現することはできない