- 1 名前：デフォルトの名無しさん mailto:sage [2023/01/17(火) 12:41:32.25 ID:nikBFIMQ.net]
- 公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust
公式ドキュメント
https://www.rust-lang.org/learn
Web上の実行環境
https://play.rust-lang.org
※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/
※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust
※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/
※次スレは原則>>980が立てること
前スレ
Rust part18
https://mevius.5ch.net/test/read.cgi/tech/1670663822/
- 41 名前：デフォルトの名無しさん [2023/01/22(日) 02:33:12.00 ID:5IaN6zUW.net]
- 書籍で最初に読むとしたら
平家蟹の方？
それとも可愛い方？
- 42 名前：デフォルトの名無しさん mailto:sage [2023/01/22(日) 02:45:54.00 ID:DAK16wxY.net]
- 平家蟹がかわいくないとか、こいつアンチか？
- 43 名前：デフォルトの名無しさん [2023/01/22(日) 02:46:40.77 ID:4BdfAMug.net]
- >>39
>GUIへの対応方法もよくわからない。
GUIのレイヤーまでResultを戻してErrならエラー表示をするだけ
- 44 名前：デフォルトの名無しさん mailto:sage [2023/01/22(日) 12:43:00.06 ID:WLCvNrGP.net]
- >>39
ログはログ。何が起きたか記録するだけ。ログレベルが何であれ副作用は起こさない。
エラーはエラー。発生したときにどうハンドリングするかはプログラムの性質で決める。
パニックはそのまま稼働したらまずい状況に陥ったら時だけ起こす。
- 45 名前：デフォルトの名無しさん [2023/01/22(日) 14:52:04.22 ID:RMpOCJx1.net]
- >>41
モンタギュー蟹の方
- 46 名前：デフォルトの名無しさん [2023/01/22(日) 15:29:33.81 ID:WCVJRVcD.net]
- アプリケーションのレイヤーでパニック起こすのはバグの時だけ
- 47 名前：デフォルトの名無しさん mailto:sage [2023/01/25(水) 16:19:44.22 ID:zlgPT3s2.net]
- ネットワーク前提にしてる時に、panicになるのはバグではないよ？
- 48 名前：デフォルトの名無しさん mailto:sage [2023/01/25(水) 16:35:00.31 ID:LG3Fy/yw.net]
- うっわすっげー読みやすいコードと思ってよく見てみたら
過去に自分が書いたやつだった(´･ω･｀)
- 49 名前：デフォルトの名無しさん mailto:sage [2023/01/25(水) 16:39:27.19 ID:5onhVltK.net]
- 天才か？
- 50 名前：デフォルトの名無しさん mailto:sage [2023/01/25(水) 16:40:49.73 ID:GSIKYco3.net]
- 過去の自分は他人だと思え、がプログラミングの基本
- 51 名前：デフォルトの名無しさん mailto:sage [2023/01/25(水) 17:17:39.71 ID:xORIlv/9.net]
- 過去のことを忘れていても過去の自分が考えることは今の自分が考えることとあまり差がない。
名前の付け方とかは何度考えても同じような状況なら同じ名前を付けるし。
書くときに想定する読み手が全くの他人のときと未来の自分のときではちょっと違う意識があるな。
- 52 名前：デフォルトの名無しさん mailto:sage [2023/01/25(水) 18:36:03.64 ID:V9gmFqbx.net]
- 一度も使ったことがない機能は書くことはできても読めると思うな、が基本
使ってから読め
- 53 名前：デフォルトの名無しさん mailto:sage [2023/01/25(水) 19:53:08.97 ID:sck5kayB.net]
- >>47
ネットワークこそ途中で途切れること前提に書かないといけない機能の最たるものだろ。エラー返してハンドリングしろ。
- 54 名前：デフォルトの名無しさん [2023/01/25(水) 20:37:11.28 ID:5EKz9Dxo.net]
- >>48
あるあるだね
- 55 名前：デフォルトの名無しさん [2023/01/25(水) 20:38:19.94 ID:xtWPaGBn.net]
- >>47
なんでpanicになるの？
- 56 名前：デフォルトの名無しさん mailto:sage [2023/01/25(水) 21:43:02.36 ID:jK9fbSTx.net]
- >>38
一度ポシャってるけど実装される可能性はあると思う
https://github.com/rust-lang/libs-team/issues/144
- 57 名前：デフォルトの名無しさん mailto:sage [2023/01/25(水) 23:55:49.39 ID:7h2BZmgN.net]
- bool以外でも&&と||の遅延評価が使えるようになるわけか
欲しいね
- 58 名前：デフォルトの名無しさん mailto:sage [2023/01/26(木) 00:47:59.28 ID:Oik+f0Gv.net]
- bool以外でもifを使えるといえばif letで
elseを省略することで3項ではなく2項演算のようになるのも&&と同じ
だがelseを省略できても{}を省略できなければ意味がない
- 59 名前：デフォルトの名無しさん [2023/01/26(木) 11:05:43.50 ID:G0iCERKY.net]
- >>58
もうちょっと基礎を勉強してからレスしろ
- 60 名前：デフォルトの名無しさん [2023/01/26(木) 11:09:10.89 ID:QY5r5/0E.net]
- すまんが、これの解答はmutをつけろっていうことなのはわかるけどさ
https://github.com/rust-lang/rustlings/blob/main/exercises/variables/variables4.rs
なんで8行目で所有権を失って9行目で代入できなくなったりしないの・・・・？
- 61 名前：デフォルトの名無しさん [2023/01/26(木) 11:24:13.84 ID:DDvWU5a2.net]
- >>60
これはもっともな疑問
The Bookのどこかに書いてたように思うけど
ざっくり言えばprintlnはreferenceを取るから所有権は移動しない
DisplayトレイトやDebugトレイトのメソッドシグニチャを見ると分かる
- 62 名前：デフォルトの名無しさん mailto:sage [2023/01/26(木) 11:33:53.75 ID:Y60o/Mze.net]
- >>60
ついこないだ Teratail で同じような質問を見たぞ。
マクロは構文糖を作り出す仕組みなので展開形によっては所有権を取ることも借用なことも何にも使いすらしないということもある。
- 63 名前：デフォルトの名無しさん mailto:sage [2023/01/26(木) 14:03:27.91 ID:YuUaXpq9.net]
- ある関数の&mut T型の引数として、T型の変数を貸すのは分かるけど
&mut T型の変数を又貸しするのが不思議
なぜmoveしたことにならないのか
- 64 名前：デフォルトの名無しさん mailto:sage [2023/01/26(木) 15:25:17.84 ID:MCrVnhV0.net]
- >>63
&TはCopyだからmoveしないよ
- 65 名前：デフォルトの名無しさん [2023/01/26(木) 15:35:28.34 ID:SkvAt80a.net]
- >>63
implicit reborrowのことかな？
&mut Tの又貸しと言ってるのがどういうケースなのかはコードかないハッキリはわからないな
- 66 名前：デフォルトの名無しさん mailto:sage [2023/01/26(木) 17:21:49.46 ID:YuUaXpq9.net]
- implicitly reborrowedされるとhogeが&mut *hogeになるのか
勉強になった
ありがとう
- 67 名前：デフォルトの名無しさん mailto:sage [2023/01/26(木) 18:45:49.05 ID:nglgEIPC.net]
- 結局&mutを持っている間は専有しているから既存ルールに抵触することなく貸し出し自由自在という理解でいいのかな
&*でimmutableなreborrowも出来ちゃうもんね
- 68 名前：デフォルトの名無しさん mailto:sage [2023/01/26(木) 19:48:43.33 ID:16g2h/GU.net]
- >>60
変数が値を所有しているんだよ
値がムーブされて一度無効化された変数にも新しい値を所有させられるよ
例えば、その9行目でxが3を所有していなかったとしても新しい値を入れられるよ
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=657d792c80f30e9430f0fbff11556fe6
- 69 名前：デフォルトの名無しさん mailto:sage [2023/01/26(木) 19:50:53.34 ID:uBPDOaY+.net]
- 暗黙で参照が外されることがあるからわかりにくいんだろうな
最初から暗黙の参照外しがなければよかったと思うが
後方互換性を大事にするなら、もう改善は不可能だな
- 70 名前：デフォルトの名無しさん mailto:sage [2023/01/26(木) 20:31:02.62 ID:q1WzF/2m.net]
- >>53
だからバグじゃないよね？
- 71 名前：デフォルトの名無しさん [2023/01/26(木) 21:11:51.00 ID:BacNCpeu.net]
- >>70
エラーを返すんだからpanicしないだろ
- 72 名前：デフォルトの名無しさん [2023/01/26(木) 21:14:28.71 ID:GObOayQz.net]
- >>68
そりゃmutならなw
- 73 名前：デフォルトの名無しさん [2023/01/26(木) 21:18:17.56 ID:q8T2WGhT.net]
- implicit reborrowはThe Bookには書かれないし直感的でもないから動きが理解しにくいというのはよく分かる
- 74 名前：デフォルトの名無しさん mailto:sage [2023/01/26(木) 21:50:47.31 ID:ZxPs9rBQ.net]
- >>70
例えばtwitterアプリを地下鉄とか通信できない状況で起動して panic で落ちる事を考えてみろ。そりゃバグだろ。
- 75 名前：デフォルトの名無しさん mailto:sage [2023/01/26(木) 22:06:21.53 ID:HEA6MC1t.net]
- Deref無しは流石にきついな
一気にRust書きたくなくなる気がする
- 76 名前：デフォルトの名無しさん mailto:sage [2023/01/26(木) 22:20:38.36 ID:nglgEIPC.net]
- >>69
むしろderef含めたcoercionのおかげでRustは便利かつ読みやすいと思う
初心者の最初のうちだけは混乱するかもしれないけどそのデメリットを誤差にするほどの絶大なメリットがある
- 77 名前：60 [2023/01/27(金) 11:24:22.85 ID:CSClNfzp.net]
- 教えてくれてるのは本当にありがたいんですが、訳がわかんないぽ・・・・
- 78 名前：デフォルトの名無しさん [2023/01/27(金) 11:51:57.32 ID:YDsF+xqw.net]
- >>77
何がわからないのか書いて
- 79 名前：60 [2023/01/27(金) 13:58:30.55 ID:CSClNfzp.net]
- マクロが展開するコードがあって、そこに&がついてるってことなんですか？
- 80 名前：デフォルトの名無しさん mailto:sage [2023/01/27(金) 14:00:09.55 ID:MqPTrKVr.net]
- せやで
Playgroundの左上のボタンでShow HIRするとマクロ展開等終わった後のコード出るから見てみ
- 81 名前：デフォルトの名無しさん mailto:sage [2023/01/27(金) 19:13:43.59 ID:q2LYouLt.net]
- &はついてるけどあなたの疑問とは関係ないと思う
- 82 名前：デフォルトの名無しさん mailto:sage [2023/01/27(金) 21:29:03.39 ID:N1uoRX56.net]
- >>74
例がtwitterアプリって...通信が出来ない状態でも何らかのオフライン操作が行えるアプリであればそうでしょうが
仕様上、エラーハンドリングを行わなければならないとされていないならバグではないでしょ....
むしろ大したログやコンソールでの情報も出さず、「エラー：通信ができましぇん」なんて返されるほうが迷惑だわ
- 83 名前：デフォルトの名無しさん mailto:sage [2023/01/27(金) 21:54:30.76 ID:cQ0vJjwr.net]
- >>82
バグかどうかは仕様次第というのはそりゃそうなんだけど、それじゃ建設的な議論にならんでしょ。
俺はError返しといたほうが利用側がハンドリングする余地があっていいと思うね。
- 84 名前：はちみつ餃子 mailto:sage [2023/01/28(土) 02:45:04.16 ID:OM0pptP0.net]
- >>82
Rust の文化にあまり詳しいわけじゃないけど panic を呼び出すのって C/C++ で言うところの assert 的なもんでしょ。
普通に考えたら panic が呼ばれるのはモジュールの仕様に対して使い方が間違っているかリカバリ不可能な場合。
逆に言えば使い方が正しくてリカバリ可能な状況で panic になるべきではない。
モジュールの使い方が完璧に正しいプログラムを書いても panic が引き起こされてしまうなら panic の使い方のほうが間違ってる。
絶対に通信が確立する状況で使えという仕様を設定すりゃあ間違ってるのは使い方のほうではあるけどさー、
ネットワークでそれは不可能な前提じゃん？ ありえない前提を元にするのは不毛だろ。
- 85 名前：デフォルトの名無しさん mailto:sage [2023/01/28(土) 07:46:19.92 ID:NqcfPhRT.net]
- >>82
> 仕様上、エラーハンドリングを行わなければならないとされていないならバグではないでしょ....
仕様バグ...
- 86 名前：デフォルトの名無しさん mailto:sage [2023/01/28(土) 09:58:07.00 ID:40nYh31B.net]
- ユーザーにとって不自然な動作をすれば開発者が仕様だと言い張ったところでそれはバグだよ
- 87 名前：デフォルトの名無しさん mailto:sage [2023/01/28(土) 10:54:36.16 ID:9JWZ6Tol.net]
- エラーにも回復可能なエラーと不可能なエラーがあり、panicすると回復不可能な状態になるんだから、回復可能なエラーはpanicすべきじゃない。ましてや通常使用でしばしば発生する状態でpanicするのは言語道断だわな。
- 88 名前：デフォルトの名無しさん mailto:sage [2023/01/28(土) 10:57:15.78 ID:A5TUrW0u.net]
- assertというかexitやな。推奨はされん、普通はデバッグで面倒な時くらいじゃないか。
- 89 名前：デフォルトの名無しさん mailto:sage [2023/01/28(土) 11:52:23.17 ID:NqcfPhRT.net]
- >>86
MSの開発者を説得してくれ
- 90 名前：デフォルトの名無しさん mailto:sage [2023/01/28(土) 11:54:06.56 ID:NqcfPhRT.net]
- >>88
exitは正常終了でも呼ばれるからassertのほうが意味的には近いと思うぞ
- 91 名前：デフォルトの名無しさん mailto:sage [2023/01/28(土) 14:06:35.25 ID:qTYDIi6E.net]
- マルチスレッド界隈ではスレッドの一つや二つ終了しても
回復不可能と思ってないでしょ
- 92 名前：デフォルトの名無しさん [2023/01/28(土) 14:59:51.08 ID:pTjpQsNq.net]
- The Bookにある回復不可能かどうかという判断基準は曖昧であまり役に立たない
Resultを伝播させてトップレベルでログ出力でもしてabortさせるのに比べて
問題発生箇所でpanicさせるメリットは処理をinfallibleな関数として定義出来ること
逆に言えばバグでも無いのにinfallibleな関数呼び出しでpanicで落ちるような設計はそれ自体がバグの可能性大
- 93 名前：デフォルトの名無しさん mailto:sage [2023/01/28(土) 17:20:49.61 ID:qTYDIi6E.net]
- 0か1かではなくバグが何個あるのかも重要
落とせば一つ？
進めれば二つ以上？
- 94 名前：デフォルトの名無しさん [2023/01/28(土) 17:59:00.91 ID:b6xT90Ev.net]
- >>93
イミフ
- 95 名前：デフォルトの名無しさん mailto:sage [2023/01/28(土) 19:43:12.93 ID:qTYDIi6E.net]
- >>86
開発者なんていないよ、みんなユーザーだよって言い張ったのがオープンソースだね
- 96 名前：デフォルトの名無しさん [2023/01/28(土) 21:12:57.88 ID:ZIiiTUHL.net]
- >>95
イミフ その3
- 97 名前：デフォルトの名無しさん mailto:sage [2023/01/28(土) 22:16:55.89 ID:qTYDIi6E.net]
- ユーザーと開発者を分断して対立煽るのをやめようってことだよ
- 98 名前：デフォルトの名無しさん mailto:sage [2023/01/28(土) 23:41:24.90 ID:j4/fJAgO.net]
- 自分(たち)で用いるツール類だけは
自明な前提を満たしていない場合に限り
エラー処理をサボったpanicで終わらせてもよい
それ以外のpanicは状態矛盾など続行不可禁止で発生するが
正しくエラー終了させるべきものであり
panic発生はバグと呼んでも差し支えない
- 99 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 01:28:33.47 ID:K5ah9cLk.net]
- >>98
panicをハンドリングしないのはバグかどうかは仕様次第と完全に認めてるのに、建設的な議論って・・・
作法的な話や、ユーザーフレンドリなUIでエラーメッセージを出したい、いきなり終了して欲しくないのであってもプロジェクトごとに異なるし、一般的な普遍性なんて「仕様上」に何が言いようがあるんだ？
オレはいつもこうしてます！という癖だったらいくらでも言えるし、100人集めてアプリケーションのレイヤーでpanicをハンドリングする/しないでアンケートしてどっちが人気かで正しさが決まるようなものではない。
最終的に「アプリケーションのレイヤーでパニック起こすのはバグの時だけ」とかいうのは明らかに間違ってるでしょ
そうするような特定のプロジェクトの仕様がたまたま（確率的に）一致するかもしれないが、それも一般化できる話ではないよ。
まあ、お望みの建設的な議論をするなら、アプリケーションをライブラリのように使用できる余地があるならResultsなどでErrorを返すのはとても良いですが、それでもpanicをハンドリングしてErrorで返すべきでは”無い”でしょうね
なぜならRustはそれを推奨していないし、Errorチェックしてをpanicに変換する方向性はあっても、panicをErrorに変える方向性は、仮にログ出力してもpanicの握り潰しやエラー情報の欠落に等しい。（なぜならログへのI/Oエラーになってる可能性もあるから）
それは、そもそもRustのpanicは言葉上は回復不能なエラーであり、バグではなくメモリーに物理的な障害が発生して配列インデックスが変になったとか、処理が続行できない、もしくはいったん特定の場所に戻って回復できないときに使われる思想。
なので、panic->Error変換処理が正常に働くかも怪しい。だからRustはそれを捉えず上位へ流して最低限やるスタックの巻き戻しのみ処理を推奨し、即座に終了させる（＝プログラムが落ちる）
Linusはこのスタックの自動巻き戻しがとても気に入らないらしいが、理由は巻き戻し処理が正常に働く理由が無いからだ。
それを無理やり捉えて、スタックトレースが出るのが嫌、即座に終了するのが嫌、は分かるけどpanicで終了したからと言って仕様に書いてなければバグじゃないでしょ
これを癖でやってしまうのはtry-catch構文があるC#やJava系から来た人が多いのではないかな...？
- 100 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 02:35:07.62 ID:r5isV+tS.net]
- 誰もpanicをResultに変換する話はしとらんやろ
- 101 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 07:18:58.36 ID:ksaPk66E.net]
- て言うか>>99は前半と後半で矛盾してるしアホほど長文を証明してるw
- 102 名前：デフォルトの名無しさん [2023/01/29(日) 11:17:47.92 ID:p51Kojpz.net]
- panicは仕様に書いてなければバグでしょ
どんなプログラム書いてんだよ
- 103 名前：デフォルトの名無しさん [2023/01/29(日) 11:27:06.90 ID:FaEg6ckP.net]
- エラーハンドリングという言葉をpanicをハンドリングしてResultにすることだと思ってたのか
そりゃ噛み合わないわな
- 104 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 13:10:21.68 ID:ZDOIjMr/.net]
- 例えばpythonのexitの代用としてpanicを使ったところで何の問題もない
- 105 名前：デフォルトの名無しさん [2023/01/29(日) 14:45:33.86 ID:ttNbSKVN.net]
- 問題ありまくり
同じexitがあるのにわざわざpanicで代用するメリットは何？
- 106 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 15:29:55.13 ID:yzACUqHq.net]
- まずは異常終了と正常終了を分断するメリットを知る必要がある
- 107 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 15:33:47.16 ID:ZDOIjMr/.net]
- >>105
へー今初めて知った
The BookのCommon Programming Conceptsあたりにそれっぽい記述はないし
中断したければpanicするしかないと思っていたよ
後学のためにどこで解説されているのか教えてほしいな
- 108 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 15:48:49.58 ID:CZoRokqJ.net]
- panic!すべきかするまいか
https://doc.rust-jp.rs/book-ja/ch09-03-to-panic-or-not-to-panic.html
- 109 名前：デフォルトの名無しさん [2023/01/29(日) 17:07:54.00 ID:qjfBPBdR.net]
- >>107
The Bookの12章を復習して
https://doc.rust-lang.org/book/ch12-00-an-io-project.html
ただThe Bookは他言語から来た人が最初に読むチュートリアルとして用意されてるものなのでカバーされてない内容も多々あるし深い解説がされてるわけでもない点は理解しておいた方がいいよ
- 110 名前：はちみつ餃子 mailto:sage [2023/01/29(日) 17:16:49.84 ID:2OIx0YXk.net]
- 標準ライブラリのマニュアルでも panic! はバグを説明するために使うということは書いてあるね。
https://doc.rust-lang.org/std/macro.panic.html
- 111 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 18:20:40.83 ID:yP5ym/xP.net]
- >>107
exitはプロセスの終了状態コードを伝えることを兼ねたOSシステムコールだから通常の言語には必ずある
そしてそのことを分かっていればRust初心者であってもstd::process::exitをすぐに見つけられる
- 112 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 18:41:07.89 ID:qSgQK/Ke.net]
- >>105
Pythonのsys.exitと同じ感覚でstd::process::exit使うほうがはるかに問題では？
少なくとも異常終了に使う分にはpanic!のほうがsys.exitに近いと思うよ
sys.exit()
https://docs.python.org/3/library/sys.html#sys.exit
・SystemExit例外を投げるだけ
・メインスレッドで実行して、かつ例外がトップレベルまで捕捉されなければ、通常の例外機構に従ってプロセスが終了する
→finallyとかwithでリソース解放書けばちゃんと解放される
std::process::exit()
https://doc.rust-lang.org/std/process/fn.exit.html
・無条件でプロセスを終了させる
・実行スレッドも他のスレッドも一切スタック巻き戻しが行われない
→デストラクタ呼ばれない
- 113 名前：デフォルトの名無しさん [2023/01/29(日) 18:45:14.86 ID:jE2G9ZiM.net]
- _exit()はシステムコールだけどexit()はライブラリの関数
pythonのexit()やsys.exit()は基本的にexitcodeを設定してSystemExit例外を投げてるだけ
os._exit()がprocess::exit()に近い
- 114 名前：デフォルトの名無しさん [2023/01/29(日) 18:46:31.90 ID:jE2G9ZiM.net]
- >>112
例外のある言語と同じ感覚でプログラミングするのが一番の問題
それ抜きにpythonと比べとも意味ないよ
- 115 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 18:48:13.88 ID:yP5ym/xP.net]
- 一般的な他の言語におけるtry-throw-catchの機能が欲しいならば
それはRustやGoなどでは意図的に排除されていて存在しない
RustではResultで返すだけでよく利便性と効率を両立させている
- 116 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 19:53:25.69 ID:ZDOIjMr/.net]
- >>109
そこは見ているけど制御機構を説明しているところで同時に解説すべきなのでは
>The Bookは他言語から来た人が最初に読むチュートリアルとして用意されてるもの
なおさら他言語でメジャーな機能や実装と対比した解説が必要では
>>112
unwind不可なのは使いにくい場面が少なからずありそう
今作っているのはdrop使っているから強制abortは問題しかない
- 117 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 21:27:11.45 ID:yzACUqHq.net]
- RustのdropにはRcという具体的な目的がある
Rcが完璧主義ではないのでdropも完璧にする必要を感じない
- 118 名前：デフォルトの名無しさん [2023/01/29(日) 21:32:58.27 ID:ns31yZLJ.net]
- >>112
>Pythonのsys.exitと同じ感覚でstd::process::exit使うほうがはるかに問題では？
RustではResultをmainまで戻してからprocess::exitする
Pythonは例外という仕組みでランタイムがそれをやってくれる
panicはやってることがにてるからという理由で使うようなものじゃない
- 119 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 21:46:05.85 ID:hfoWSJ8/.net]
- >>115
そうではないよ？例えばrustの標準ライブラリのTcpStreamにはset_read_timeoutでタイムアウトを設定すると、それ設定値以上でpanicを起こす。
これは通信中に非同期制御やスレッド監視などをしないための苦肉の策でResultをmatchするだけという考えから外れて、回復不能としているのだがリードタイムアウトであろうと再試行するようなプログラムではpanicを考慮しなければならない。
一方でTcpStreamの多くはResult<>を返すので、高度なプロトコルを作るような場合、受け取ったデータなどを調べてpanicさせる方法などが公式ドキュメントにも述べられている。
- 120 名前：デフォルトの名無しさん [2023/01/29(日) 21:46:28.34 ID:6XW+IoFB.net]
- The Bookに書いてるようにpanicを使う対象となるような回復不可能なエラーは常にバグによるもの
Rust groups errors into two major categories: recoverable and unrecoverable errors.
Unrecoverable errors are always symptoms of bugs.
- 121 名前：デフォルトの名無しさん [2023/01/29(日) 21:56:31.01 ID:saQmfbkd.net]
- >TcpStreamにはset_read_timeoutでタイムアウトを設定すると、それ設定値以上でpanicを起こす。
readで設定したtimeout値を超えたらpanicすると言ってる？
少なくともリファレンスにはResultが返されるとあるんだが
- 122 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 21:57:37.90 ID:K3YIwpIF.net]
- >>113
_exitはexit_groupのラップ関数だよ
- 123 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 22:09:10.65 ID:+VDCQEdm.net]
- 言語の理想と実装は違うから食い違いが出ている。現実的には作者がめんどくさくなったり、ライブラリとそれを利用するレイヤーの区別があいまいな場合などに大域脱出とスタック巻き戻しがしたいだけで回復可能な場合にもpanicを投げてしまう実装もありうるのでバグではない。標準ライブラリでさえそうなのだから
- 124 名前：デフォルトの名無しさん [2023/01/29(日) 22:14:20.10 ID:jL8Axswy.net]
- > 受け取ったデータなどを調べてpanicさせる方法などが公式ドキュメントにも述べられている。
これはpanicを使えということじゃなくサンプルコードとしての簡潔さ優先してるだけ
改善はされてきてるけどunwrapがあちこちにあるのと同じ
箸の上げ下げレベルで手取り足取り教えてもらうことを期待し過ぎじゃないか
- 125 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 22:21:53.21 ID:qSgQK/Ke.net]
- >>118
うん別に良いデザインではないよ、そこは同意する
俺は「同じexitがあるのに」という表現が招きかねない誤解に釘を差しただけです
- 126 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 22:33:36.00 ID:+VDCQEdm.net]
- >>124
もちろんドキュメントで述べられてる通り、Resultが一番の選択肢で回復可能で返せるのにpanicを使うのは愚策でしょう。だから理想はとそういってますよね？
手取り足取り教えてもらうのはどちらなのかというよりも、どうしてもpanicで終了はバグだという理想・意見をとゴリ押ししたいだけに見えます。
これは（＝回復可能なのに）panicを使えということじゃなくというのは強く同意ですが、そうなっていないものを使用している現実があるという話でpanicを書いてないことに期待し過ぎじゃないか？ということになります
- 127 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 22:38:36.38 ID:yP5ym/xP.net]
- >>119
Rustでそのような形のpanicの使われ方はしませんしpanicは起きません
タイムアウトもio::Resultでio::Errorが返るだけです
これはC言語で書いてSO_RCVTIMEOでタイムアウト値を設定してreadで-1とerrnoが返る時と全く同じ状況です
言語独自の例外機構を持つ言語は複雑にしてややこしくしているだけなのでその考えをまず捨てるところからスタートしましょう
- 128 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 22:44:10.80 ID:yP5ym/xP.net]
- >>126
今回のケースでも標準ライブラリはpanicを起こしていませんしpanicを起こす仕様はありません
もしpanicが起きたのならばそれはあなたがResultの処理をせずに強引にunwrap()したためであり
あなたのコードがpanicを引き起こしたのです
- 129 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 22:49:39.52 ID:ZDOIjMr/.net]
- The BookにmainまでResultで戻す実践的な設計方法って解説されてる？
機能の説明はあっても実装するうえでどのようにしたらいいのかってところは抜けているような
ググるとstd::num::*を返す例、Stringを返す例、enumを返す例などが出てくるが
どのように使い分ければいいのかって点は不明
このスレ見ていてもこの部分に関する資料を提示している人は見かけないし
>>124
>箸の上げ下げレベルで手取り足取り教えてもらうことを期待し過ぎじゃないか
箸文化圏なら要らないだろうがスプーン・フォーク文化圏なら要るんじゃね
他所と大きく違うのであれば十分な説明を求められるのは当然では
- 130 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 22:51:25.05 ID:CZoRokqJ.net]
- > 例には、不正なデータを渡されたパーサとか、 訪問制限に引っかかったことを示唆するステータスを返す
> HTTPリクエストなどが挙げられます。 このような場合には、呼び出し側が問題の処理方法を決定できる
> ようにResultを返してこの悪い状態を委譲して、 失敗が予想される可能性であることを示唆するべきです。
> panic!を呼び出すことは、 これらのケースでは最善策ではないでしょう。
- 131 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 23:19:15.93 ID:B9jwmLl6.net]
- >>129
mainまでResultで戻すにはResult型を返す関数を書くだけ
何も難しいことはなく複雑なこともなくシンプル
Resultは単なる型の一つでOk値とErr値のEnumに過ぎない
Rust言語はResultに対し例外機構のような特別扱いをしていない
ResultはTryをimplしてるから『？』オペレータを適用できるなどくらいしか他の型との違いはない
したがって新たに勉強すべき点はそこだけだが『？』は使わずとも同じことを記述することができる
- 132 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 23:31:48.93 ID:ZDOIjMr/.net]
- >>131
Result<T, E>のEってなしに出来たっけ？自分が言いたいのはそういう話なんだけど
- 133 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 23:45:24.52 ID:B9jwmLl6.net]
- >>132
特別扱いはないので自由
例えばbool相当としてResult<(),()>型を使ってももちろん機能する
またOption<T>相当としてResult<T,()>型
通常はそれぞれ前者を使って必要なところで初めてResultへ変換が普通
- 134 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 23:50:28.46 ID:X9CS5Y/7.net]
- >>129
> The BookにmainまでResultで戻す実践的な設計方法って解説されてる？
12章はどうだろうか、minigrep を作るところ
- 135 名前：デフォルトの名無しさん [2023/01/29(日) 23:59:14.71 ID:/s+aPXiv.net]
- >>129
12章に書いてるでしょ
それに一連のレスで書いてる設計指針はRust特有の話じゃないよ
アプリのトップレベルに集約エラーハンドラを用意するのは例外機構のある他の言語でも同じだし
エラー発生時にexitcodeを設定してプロセス終了させるのはUIに相当するレイヤーの仕事だからそこまで戻してハンドリングするのも他の言語でも同じ
pythonだとしてもいろんなレイヤーでsys.exitするのは典型的なダメなやり方
- 136 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 23:59:23.38 ID:B9jwmLl6.net]
- RustはResultを特別視しない
例えばGoのようにRustで(正常値, エラー値)とタプルで返す関数群でプログラミングしても同様に動く
じゃあなぜResultを用いるのか？
・統一した型があった方がいい
・二値ではなく二種のEnumでよい
・便利なメソッド群を標準で用意できる
・標準ライブラリをResultで統一できる
- 137 名前：デフォルトの名無しさん [2023/01/30(月) 00:00:50.47 ID:M6Z3pSeY.net]
- すまん被ってた
- 138 名前：デフォルトの名無しさん [2023/01/30(月) 00:02:36.60 ID:RUd1b+83.net]
- >>132
なんでEを無くしたいの？
- 139 名前：デフォルトの名無しさん [2023/01/30(月) 00:09:50.85 ID:Oa/BEQbJ.net]
- Rust特有のエラーハンドリングの実践的な知識はanyhow/thiserrorの使い方を学ぶといい
それらのcrateを使わず自前でやるとしても何を用意する必要があるのかわかる
- 140 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 00:14:09.92 ID:q9Kf6jE6.net]
- 副作用がない関数なら大域脱出を使うべきでないのは分かる
副作用に寛容で大域脱出に不寛容なのは分からん
- 141 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 00:19:52.36 ID:1Kzq/YqA.net]
- >>139
それは初心者には混乱の元
panicとか言ってる初心者たちが最初にすべきことは一つ
「unwrap()を使わずにプログラムを書く」
|
 |
