Rust part19

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/ 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()を使わずにプログラムを書く」 142 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 08:11:22.12 ID:sNrNLjHp.net] >>109 >The process::exit function will stop the program immediately and return the number that was passed as the exit status code. >This is similar to the panic!-based handling we used in Listing 12-8, but we no longer get all the extra output. >・・・ >Great! This output is much friendlier for our users exitの使用目的はpanicによる不必要なメッセージの抑制に読めるけど？>>112で触れられている副作用なんか完全スルー それに明らかに大域脱出を意図した使い方 裏を返せばpanicのメッセージ出力が問題にならないのであればpanicでも構わないとも取れる 143 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 08:21:18.23 ID:e4IM4WvI.net] もういいよ。お前はずっとpanic使っとけ。 144 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 08:28:01.11 ID:1Kzq/YqA.net] Rustをきちんと学ぶ気があるならば まずはpanicもunwrapも使わずにプログラムを自在に書けるようになること そういう基礎ができていないから勘違いしてpanicにこだわろうとしてしまう 145 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 08:31:46.93 ID:uyNTp5VX.net] 評判の悪いthe book 日本語版にすら使い分けの記述あるのに、それを無視して回復不能なエラー処理以外でpanicを推奨しようとするのは何なのかね。 エラー処理 Rustには例外が存在しません。代わりに、回復可能なエラーにはResult<T, E>値があり、 プログラムが回復不能なエラーに遭遇した時には、実行を中止するpanic!マクロがあります。 146 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 08:40:51.18 ID:VdE13u+1.net] the bookを一通りきちんと読んだならunwrapは極力使うべきではないものだと理解できるはずなんだけどな 147 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 11:00:50.02 ID:R3gVBmE3.net] >>138 panicで大域脱出して構わない状況ならmainで必要な情報はreturnするか否かだけ これはResultが保持しているのでEは不要 148 名前：デフォルトの名無しさん [2023/01/30(月) 11:23:44.77 ID:hiS6eSAP.net] >>147 すまんけど全然わからない TとEの両方がないとResultが存在できないと思うんだが 149 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 11:26:30.09 ID:q36OfC0i.net] TとEを()にしたら実質ないなので 150 名前：デフォルトの名無しさん [2023/01/30(月) 11:36:33.64 ID:2ZbeByHM.net] >>142 ちゃんと読もう そして全体の文脈を理解しよう https://doc.rust-lang.org/book/ch12-03-improving-error-handling-and-modularity.html#fixing-the-error-handling 151 名前：デフォルトの名無しさん [2023/01/30(月) 11:50:16.61 ID:xWvH9QlK.net] >>149 Eをunit typeにすることをEをなしにすると言ってることは理解したが >panicで大域脱出して構わない状況ならmainで必要な情報はreturnするか否かだけ これは全然わからない 大域脱出したいからpanic使いたがってるという動機部分は理解した 152 名前：デフォルトの名無しさん [2023/01/30(月) 12:08:29.21 ID:xWvH9QlK.net] exitcodeをちゃんと実装したい時は process::exitのリファレンスに書いてるように mainの戻り値にTerminationを実装した型を指定してprocess::exitは使わずmainから戻り値を返す方法が今は推奨 153 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 12:56:41.01 ID:WhTmZ0y4.net] >>151 処理継続不能なら終了するしかないからね。panicで終了しようが、mainまで戻ってからreturnしようが大差ない 154 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 19:01:04.95 ID:uxYUj7Ri.net] >>153 いやいや、深いところから脱出するのにResultだと途中の階層すべてで返さないとダメだからコーディングの手間が全然違うだろ 155 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 19:07:00.52 ID:6jXELBYF.net] >>154 でもアンチpanic君？はその手間を正当化したいっぽいじゃん 156 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 19:15:25.77 ID:mQYOoXSo.net] 日曜プログラマーの作るソフトときちんと作るソフトで基準がズレてる感じ 157 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 19:23:44.43 ID:mT8msQLw.net] そうやってすぐ人格の問題にする

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef