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

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

むろん「0で割らせたくないなら NonZeroI32 とかを引数に取れ」というのもまた合理的であって、組み込み除算でそうなってないのは単にパフォーマンスと利便性のためだとは思いますが。

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

少なくとも「0が来たらｼﾗﾈ」という仕様のもとで fn div(x: i32, y: i32) -> Result<i32, ZeroDivError> は意味があるように見えないと思いますし、その点で「仕様上認められないことが発生したら、 (仕様がおかしいか実装がおかしいかはさておき) それ以上の遂行を阻止すべくクラッシュ」は妥当かと

Ryusei @mandel59

将来的に機能を追加してErrorを返さないバージョンが作れるのであれば、その時にResult型を使わないインターフェースを用意すればいい話で、手抜きであればErrorを返すというのが一番素直

denjiry @denjiry

仕様は全部型にする縛りを破らないとするとこの時点で主義がバッティングしてそう

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

まあ i32 / i32 を禁じて i32 / NonZeroI32 にすることのみが正解だ、というのは過激だなぁとは思うけど確かに筋が通っていると思います。 fallible な型変換が最初からもっと楽にできる世界だったら私もそうすべきだと強く主張していたかもしれない…… (ほんまか)

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

std::convert::TryFrom が入ったのが Rust 1.34.0 で、割と最近なんですよね (ちなみに never type (`!`) はまだ unstable なのでそこにも若干のつらさがある)

Ryusei @mandel59

不整合は修復できないからpanicするべきってのは正しいんだけど、未実装は不整合じゃなくて、それで不整合な状態がどこにも広がっていないとわかっているなら、panicする必要はない

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

そもそも unsafe の存在を受け入れてしまった時点で「型で (あるいはコンパイラが検査できる形で) 保証を表現しきれない」という諦観が最初からあって、そういうある種の敗戦後的世界観みたいなのに生きているというのはあるかもしれない

Ryusei @mandel59

型で表現できない部分ではpanicを起こして、型システムを健全に保つ必要があります。型システムの健全性が保たれるなら、別にpanicを使う必要はないし、使うべきでもないです。

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

まあ未実装はそうですね。 私も実装初期に Error::Unsupported(String) みたいなエラーの variant 作ることあるので (もちろん最後には消すことを目標にするけど)

tom tan @tm_tn

#dlang の assert と enforce の話っぽい。 twitter.com/lo48576/status…

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

fn expect(&self, msg: &str) -> T の代わりに、 fn unwrap_which_must_always_succeed(&self, msg: &str) -> T と fn unwrap_or_panic(&self, msg: &str) -> T が欲しいと、私はそう言いたいわけです

2020-12-22 17:10:02

KOBA789 @KOBA789

仕様を全て型にするの、夢見るのはいいけど今日の仕事でやるべきではないという立場です

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

unimplemented!() は「リリースまでに消えることを想定しているが、とりあえず型は合わせたい」程度の一時的なものだと解釈している (その点では todo!() との区別がどうなのというのはあるけど)。

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

で、リリース時点で (つまり仕様上は) 存在していないべきエラーが開発中に存在しているといろいろ不都合なので、型を先に組むうえで unimplemented!() のようなものが有用である、くらいの認識

Ryusei @mandel59

モジュールの観点がないと、あんまり厳密で意味のある主張になってない気がする

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

Lint to remove unimplemented!() macro · Issue #2250 · rust-lang/rust-clippy · GitHub github.com/rust-lang/rust… rust-lang.github.io/rust-clippy/ma… なのでこんな話もありますよね

Ryusei @mandel59

panic、使うべきところでは使って、使うべきでないところでは使うべきではない（トートロジー）

Ryusei @mandel59

「不正な値」「未定義動作」にもいろいろなレベルでの不正・未定義があるっていう

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

Template enforce - D Programming Language dlang.org/library/std/ex… > `enforce` is used to throw exceptions and is therefore intended to aid in error handling. It is not intended for verifying the logic of your program. That is what `assert` is for. assert! と ensure! っぽいな

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

Panic を恐れるべからず - 何とは言わない天然水飲みたさ blog.cardina1.red/2019/12/19/don… > これは assert と同様に与えられた条件が満たされているか検査するが、満たされていなかった場合に panic するのではなく与えられたエラーを返すというマクロであり、

Ryusei @mandel59

アプリケーションレベルでの未定義動作が発生したとして、それはシステムレベルでの未定義動作ではない。UIのコードが未定義動作を起こしたら、UI自体はむちゃくちゃになるだろうが、その外側のシステムに未定義動作が波及しないようになっているべき。

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

みんな似たようなことを考えるんだなぁ (それはそう)

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

言語レベル UB とライブラリレベル UB みたいなやつだ (最近だと str 型の保証とかがその話題だった)

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

remove language-level UB for non-UTF-8 str · Issue #71033 · rust-lang/rust · GitHub github.com/rust-lang/rust… twitter.com/lo48576nsfw/st…

Not Suitable For Work / らりお・ザ・社会不適合㋞㋰㋷㋓ @lo48576nsfw

str 型は内部的には [u8] の opaque typedef であると捉えることが可能というのがまず前提。 で、「内部の (wrap された) 型としては妥当な値だが外側の (typedef 後の) 値としては不正な値である」という状況が発生したときどうするか、というのが今回の話

2020-05-30 21:54:37

電波猫 @dempacat

仕様を型で全部書くの、証明駆動開発では……