Rust part19

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 2ch.scのread.cgiへ]
Update time : 02/11 13:46 / Filesize : 165 KB / Number-of Response : 546
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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/
321 名前：デフォルトの名無しさん mailto:sage [2023/02/02(木) 08:05:47.28 ID:VrfwqxiC.net]: >>318
コンパイラ(教官)はひとつしか無いから選択肢は無いよ。
322 名前：デフォルトの名無しさん mailto:sage [2023/02/02(木) 08:14:13.18 ID:eMZEpDOV.net]: コードを貼るわけでも実装例を示すわけでもない時点でシッタカだろ
323 名前：デフォルトの名無しさん mailto:sage [2023/02/02(木) 09:11:33.63 ID:ICVq01Bq.net]: anyhow勧めてる人自身があんまり理解してないんだと思う
324 名前：デフォルトの名無しさん mailto:sage [2023/02/02(木) 12:40:03.75 ID:8vdGQp5R.net]: 複オジが使ったことないだけだろ
>>312も今調べてきました感満載じゃん
デファクトスタンダードになってるライブラリまで排除したらrustでは何もできんぞ
325 名前：デフォルトの名無しさん mailto:sage [2023/02/02(木) 12:47:49.51 ID:YyXCj6j+.net]: オライリー本にも実戦ではanyhowとthiserrorを使えと書いてる
326 名前：デフォルトの名無しさん mailto:sage [2023/02/02(木) 12:59:53.51 ID:c3pJ+FwE.net]: >>321
うまいこといいますね。お見事！
327 名前：デフォルトの名無しさん mailto:sage [2023/02/02(木) 13:20:28.44 ID:C8PK02xw.net]: 禁忌事項はライブラリを作って提供する時にanyhowを使ってしまうことだけだから
そこはanyhowを使わずにthiserrorを使えばヨシ
328 名前：デフォルトの名無しさん mailto:sage [2023/02/02(木) 15:47:50.42 ID:HD9HoUeH.net]: 別にanyhowをthiserrorに差し替えるのも大した手間じゃないしな
ライブラリで使っちゃってるなら変更PRでも出してやれば良い
329 名前：デフォルトの名無しさん mailto:sage [2023/02/02(木) 23:07:11.98 ID:3wRXRcn7.net]: >>325
anyhowとthiserrorを使うなと言ってる人は誰もいなくて
・まず先にstd::error::Errorを覚えよう
・次に?変換とdynダウンキャストを覚えよう
・そしてanyhowとthiserrorへ進もう
という話でしょ
そうすればanyhowをライブラリで使うべきでない理由もわかるでしょうし
330 名前：デフォルトの名無しさん mailto:sage [2023/02/02(木) 23:14:43.66 ID:3quZbai0.net]: Rustの世界でダウンキャストってなんかキモいな
331 名前：デフォルトの名無しさん mailto:sage [2023/02/02(木) 23:37:26.35 ID:wswA48V7.net]: むしろRust基盤の一つ
downcastはエラー処理に限らずdyn Traitを元の型に戻すために必須
anyhowでも元のエラー型に戻すために必須
332 名前：デフォルトの名無しさん mailto:sage [2023/02/02(木) 23:53:43.61 ID:86yN0Q3V.net]: ダウンキャストのソース見てみたら
やっぱりunsafeのかたまりだった
333 名前：デフォルトの名無しさん mailto:sage [2023/02/02(木) 23:53:52.64 ID:QEJ+oT50.net]: ダウンキャストを知らないと
>>303のようにdyn Errorで出来ることはログ出力だけと思いこんでしまう
334 名前：デフォルトの名無しさん mailto:sage [2023/02/02(木) 23:59:01.23 ID:Cx26n0QZ.net]: >>332
当たり前
Rustの標準ライブラリはunsafeだらけ
原理的にunsafeは避けられないからそれを安全なインターフェイスとして公開するのがRustの標準ライブラリ
335 名前：デフォルトの名無しさん mailto:sage [2023/02/03(金) 00:57:17.44 ID:teLYlQt8.net]: dynを元の型に戻すという発想に違和感（気持ち悪さ）を感じる人もいると思う
元の型に戻すつもりならそもそもdynにしないというか
ダウンキャストは戻すべき型（の変更）を全部把握できる閉じた状況じゃないと使いにくい
336 名前：デフォルトの名無しさん mailto:sage [2023/02/03(金) 01:37:41.39 ID:VgIBWdEw.net]: >>335
anyhowを使うのはそういう全部把握できる閉じた状況で
独自エラー型を用意するのが面倒な時に使うからダウンキャストが理に適っている
嫌ならanyhow使わずにthiserrorを使えばよい
337 名前：デフォルトの名無しさん mailto:sage [2023/02/03(金) 07:58:09.95 ID:+r7mcEDE.net]: >>335
型を全て把握しておく必要はない
例えばエラー処理で大半はエラー表示のみだが一部だけ特別な処理をしたいとすると
その処理したいエラー型のみダウンキャストして使えばいい

ちなみにダウンキャストは内部で定数のu64で表現される型番号をu64比較するだけなのでコストがかかるものではない
338 名前：デフォルトの名無しさん mailto:sage [2023/02/03(金) 08:54:57.66 ID:Vma9tJMI.net]: ダウンキャストの扱いかどうか知らんが、パターンマッチングも総和型から個別型ヘのキャストみたいなもんだろ。
339 名前：デフォルトの名無しさん mailto:sage [2023/02/03(金) 09:11:06.24 ID:+r7mcEDE.net]: もしdyn使わずに自作Enum収容エラー型を定義して使っても
Enumタグ比較で分岐することになるから状況は似たようなもの
340 名前：デフォルトの名無しさん mailto:sage [2023/02/03(金) 09:18:29.47 ID:H94wvEsC.net]: std::any::Any.downcast_ref() を使わずにanyhow独自に実装してるね
341 名前：デフォルトの名無しさん mailto:sage [2023/02/03(金) 09:36:29.67 ID:e19a6Rdo.net]: 初めて間もないけど
println!("{}", a);
とか手が攣って辛い
tabでもprintlnまでしかでないしコピペでもしてるの？
342 名前：デフォルトの名無しさん mailto:sage [2023/02/03(金) 09:43:50.06 ID:90dUFc67.net]: downcastすればいいだけだからdyn Error返してもデメリットは無いってのなら
ライブラリでanyhowを使うのも大した問題じゃないって結論になるん？
343 名前：デフォルトの名無しさん mailto:sage [2023/02/03(金) 10:26:25.61 ID:5QmoSp+n.net]: >>342
anyhowの問題点はそこではない
anyhowは最も重要なことを実装していない(不可能)という欠点があるため
344 名前：デフォルトの名無しさん mailto:sage [2023/02/03(金) 10:31:15.17 ID:Vma9tJMI.net]: >>343
anyhowの問題点なんて一般的じゃないんだから、曖昧に言わずに具体的に説明しなよ。
345 名前：デフォルトの名無しさん mailto:sage [2023/02/03(金) 10:48:35.31 ID:yQvnFmTM.net]: 予言しよう
ググれば分かるんだから書かないとか言って絶対に具体的な説明はしないやつだよ
346 名前：デフォルトの名無しさん mailto:sage [2023/02/03(金) 12:00:34.82 ID:7ZLHWUFf.net]: 俺はなんも知らんから頭の片隅に覚えておくくらいにしとくわ
使うときに調べる
347 名前：デフォルトの名無しさん mailto:sage [2023/02/03(金) 12:23:43.68 ID:dwx7vokg.net]: >>345
検索しても出てこなかったよ。
348 名前：デフォルトの名無しさん mailto:sage [2023/02/03(金) 12:37:16.79 ID:tbHpIbwJ.net]: Rustでエラー型はstd::error::Errorトレイトを実装するのが共通のお約束だけど
anyhow::Errorは諸事情あって実装されていないんよ
std::error::Errorトレイト実装を前提として扱っているところへライブラリがanyhow::Errorを返しちゃうと困っちゃう
ライブラリを作るときはthiserrorでエラー型を作ればstd::error::Errorトレイトを自動で実装してくれるから大丈夫だよ
もちろんthiserror使わずに自分で実装してもいいよ
349 名前：デフォルトの名無しさん mailto:sage [2023/02/03(金) 15:29:10.83 ID:Vma9tJMI.net]: >>348
「このライブラリはanyhow対応必須です。anyhow対応しないと使えません」
ならOKかね。
350 名前：デフォルトの名無しさん mailto:sage [2023/02/03(金) 18:59:27.03 ID:NDb3ccU3.net]: Box<dyn Error>もErrorトレイト実装してないよ(コンフリクトで実装できない)
その点はdyn Errorで返してもanyhowで返しても大差ない
libraryのpublicなAPIでtype erasedなエラーを返したいときは
Errorを実装した独自のエラー型を用意するのが普通
anyhowで返してる有名ライブラリもあるけどね

ライブラリでanyhow使ったらダメなんてことは特にないんだけど
Readme読めばすぐわかるように基本的にはアプリケーション用

なぜ同じ作者のエラー系のライブラリがanyhowとthiserrorと2つあるんだろうか？
と疑問に持つだけでも初心者はstdベースで学習するよりも1歩先に進めてる
351 名前：デフォルトの名無しさん mailto:sage [2023/02/04(土) 00:38:01.54 ID:5aCWsuCk.net]: ダウンキャストは静的チェックできず変更に弱いからホイホイ使うものじゃないよ
352 名前：デフォルトの名無しさん mailto:sage [2023/02/04(土) 07:20:32.73 ID:eqpqpGi8.net]: >>351
ダウンキャストは静的に型を指定して
Some()で静的な型で値が返ってきて
その値の使用も静的に型チェックされる

「マッチングが動的ではないか？」については
Enumで複数の型を収容した場合と全く同じ
どちらの場合もマッチングは動的に行われるが静的に型チェックされる
どちらも静的に型を抽象化した定数の整数値との比較によるマッチングとなる点も同じ
353 名前：デフォルトの名無しさん mailto:sage [2023/02/04(土) 09:46:17.84 ID:4OrKEijd.net]: ばかばかc
354 名前：デフォルトの名無しさん mailto:sage [2023/02/04(土) 09:59:08.11 ID:wSUDs8sY.net]: Rustのdynとそのdowncastは安全性と最小限のコストを両立させており安心して使える
引数などでimpl Traitが使える場合はimplが有利なケースもあるが
返値などでdyn Traitしか使えない場合もあり適材適所で使い分け
355 名前：デフォルトの名無しさん mailto:sage [2023/02/04(土) 10:30:58.71 ID:yB06Lfm4.net]: >>352
よくわかってないものを人に勧めちゃダメだよ
356 名前：デフォルトの名無しさん mailto:sage [2023/02/04(土) 12:22:28.04 ID:eqpqpGi8.net]: 久々に荒らし発生かな
357 名前：デフォルトの名無しさん mailto:sage [2023/02/04(土) 12:44:13.93 ID:vEFKnpWX.net]: ダウンキャストの安全性みたいなのは downcast_ref 使ってりゃ議論の余地はないと思うけど網羅性は限界があるわね。

ライブラリはやっぱエラー型を明示すべき。
358 名前：デフォルトの名無しさん mailto:sage [2023/02/04(土) 13:10:09.04 ID:QerlffZr.net]: match式によるパターンマッチでは、そのマッチアームによる条件網羅性がコンパイル時に検証される。
enumとmatch式は相性抜群だよな。
https://doc.rust-jp.rs/book-ja/ch06-02-match.html#%E3%83%9E%E3%83%83%E3%83%81%E3%81%AF%E5%8C%85%E6%8B%AC%E7%9A%84
359 名前：デフォルトの名無しさん mailto:sage [2023/02/04(土) 13:39:49.84 ID:A1ugYU/e.net]: エラー処理で網羅性は関係ないだろ
std::io::Errorのenum ErrorKindからしてnon_exaustive指定だぞ
match式で網羅性はチェックされない
特別な処理が必要なエラーだけ処理対応して残りはエラー表示が普通だ
360 名前：デフォルトの名無しさん mailto:sage [2023/02/04(土) 13:52:58.01 ID:RtFCJdnN.net]: エラー処理で重要なことは
・エラーが発生しているにも関わらずそのまま通常処理を進めないこと
・エラー表示以外の対応を必要とするエラーの場合にその対応をすること
・それ以外のエラーはエラー表示などをすること
enumタグレベルの網羅性を求められることはないな
361 名前：デフォルトの名無しさん mailto:sage [2023/02/04(土) 14:46:52.23 ID:7PnUG+Eh.net]: 元々の話はdyn Errorかanyhowか、だったような気がするけど、
anyhowはdyn Errorの自作ラッピングみたいなもので、
とちらを使ってもダウンキャストしなきゃいけない点も網羅性がない点も同じだよね。
そしてそれらをアプリ側で使ってる限り困ることもない。
362 名前：デフォルトの名無しさん mailto:sage [2023/02/04(土) 17:06:34.73 ID:1vu2ZDPp.net]: そもそもがダックタイピングとか向いてる言語じゃない。
フロントでこの言語使おうとするとかただのバカでしかないわ。
363 名前：デフォルトの名無しさん mailto:sage [2023/02/04(土) 17:36:37.29 ID:roDrLtFP.net]: 唐突にフロントとかダックタイピングとかどうした？
しかもその二つも関連性がない
364 名前：デフォルトの名無しさん mailto:sage [2023/02/04(土) 18:06:27.05 ID:uIknpDmG.net]: 上位レイヤーも含めてエラーの内容によって分岐したいならdyn Errorはやめたほうがいい
365 名前：デフォルトの名無しさん mailto:sage [2023/02/04(土) 18:34:38.01 ID:srvPtSil.net]: 分岐にenumのタグを使うかErrorの型名を使うかの違いでしょ
enumを使うと一貫性を担保しやすいから保守性が向上するし
dyn Errorを使うとenumの定義を省略できるからコードを減らせる
自分は（分岐するなら）enum派だけど何を重視するかで結論が変わりそう
ただ「やることが一緒だからどっちも同じ」と考えはいただけない
366 名前：デフォルトの名無しさん mailto:sage [2023/02/04(土) 18:40:15.09 ID:3y1LLse5.net]: >>364
dyn Errorをやめるべき理由がない
まさかと思うが代わりにanyhow使えとか言い出すんじゃないんだろうな？
367 名前：デフォルトの名無しさん mailto:sage [2023/02/04(土) 19:00:20.00 ID:eqpqpGi8.net]: dyn Errorもダウンキャストも使用して全く問題ないよ
有名どころでも普通に使われている
例えばreqwestはdyn Errorを使っていてdowncast_ref()してエラー処理している
cargoはanyhowを使っていてdowncast_ref()してエラー処理している
使うのをやめたほうがいいと主張している人は一種の宗教にすぎないことに気付こう
368 名前：デフォルトの名無しさん mailto:sage [2023/02/04(土) 22:40:19.42 ID:JjHQagj1.net]: 勘違いしてる内容が同じだから
自演しまくっても同一人物なの丸分かりだね
ダウンキャストオジ==複オジ
369 名前：デフォルトの名無しさん mailto:sage [2023/02/05(日) 02:20:20.64 ID:VCqNNrEk.net]: 無敵やな
もちろんいい意味で
370 名前：デフォルトの名無しさん mailto:sage [2023/02/05(日) 02:25:01.54 ID:a/eU++XN.net]: 一年ぐらい前にanyhowを標準化する、みたいな話なかったっけ？
371 名前：デフォルトの名無しさん mailto:sage [2023/02/05(日) 02:59:04.83 ID:26rYdUrG.net]: anyhowはダウンキャストするしかないクソ
372 名前：デフォルトの名無しさん [2023/02/05(日) 06:00:11.27 ID:TqN0qcyT.net]: オライリーの本って出てから1年経つけどさあ
これの電子版って、セールになったりする機会ってあるもんなの？
373 名前：デフォルトの名無しさん mailto:sage [2023/02/05(日) 06:31:13.67 ID:qzS4+JVd.net]: ダウンキャストを毛嫌いしてる人の心理を知りたい
374 名前：◆??? [2023/02/05(日) 12:21:29.64 ID:gCGZ2Fk+q BE:2843802656-2BP(0)]: std::mem::transmute
375 名前：デフォルトの名無しさん mailto:sage [2023/02/05(日) 12:11:30.30 ID:vL4nY6Md.net]: >>359-360
おまえはまるで何もわかってないのな
エラーハンドリングの基礎すらおさえてないじゃん
無知なのはいいが自信満々で嘘を書きまくるのはやめろ
376 名前：デフォルトの名無しさん mailto:sage [2023/02/05(日) 12:37:36.14 ID:yQ5U4c14.net]: 作るシステムの性質や分野ごとで許されるエラーハンドリングは別物だからね。
ミッションクリティカルだけが正解ってわけでもないのよ。
377 名前：デフォルトの名無しさん mailto:sage [2023/02/05(日) 14:02:09.96 ID:dIeXO9aa.net]: >>376
何がまちがってるかさえも分からないようならThe Bookを一から読み直して出直してこい
378 名前：デフォルトの名無しさん mailto:sage [2023/02/05(日) 14:22:39.74 ID:Ib1Yzzhk.net]: たまに出てくる「間違っている」「勘違いしてる」「嘘を書くな」の人
今までも文句をつけるだけで正確を書いたことがないから信頼できないのよね
379 名前：デフォルトの名無しさん mailto:sage [2023/02/05(日) 14:23:18.13 ID:8OOQa3AE.net]: どっちも自分の脳内シチュでしか語ってないからふわっふわで論破出来るわけもなし
自分の主張が通る具体例上げるといいよ
380 名前：デフォルトの名無しさん mailto:sage [2023/02/05(日) 14:35:53.55 ID:LY0V54Tb.net]: ｢カッコウのアルゴリズムさえまともに実装できてないからクソ遅いんだよな｣
みたいに適当なワード混ぜて意味不明なこと言いつつ同意してる風を装うと｢そうなんだよ！｣とか勝手に乗っかってきて自爆するから面白いぞ
381 名前：デフォルトの名無しさん mailto:sage [2023/02/05(日) 15:42:56.66 ID:XUJKjP/6.net]: >>378
それは信頼以前に、相手にしなくていい外野

>>380
すごく目に見えるわその展開ｗ
382 名前：デフォルトの名無しさん mailto:sage [2023/02/05(日) 15:53:21.98 ID:ANWYibFj.net]: >>373
台所まで行けば箸（enum）があるのに手元のフォークで焼きそばを食べてる感じ
食べてるのがパスタ（Python）なら平気なんだけど
383 名前：デフォルトの名無しさん mailto:sage [2023/02/05(日) 16:01:07.42 ID:3wawDpMD.net]: >>382
微妙にわかりにくい例えで草
でも複オジに比べると1000倍マシ
384 名前：デフォルトの名無しさん mailto:sage [2023/02/05(日) 16:04:59.96 ID:0ZBI/vwq.net]: >>378
信頼するかどうかはあなた次第
>>359-360が嘘だらけだということが分からない人は基礎がなってないから勉強やり直すかパスタにするか
385 名前：デフォルトの名無しさん mailto:sage [2023/02/05(日) 17:40:20.51 ID:X5wQdMGf.net]: 網羅性が必要ないならResult使う必要もRustを使う必要もないわな
386 名前：デフォルトの名無しさん mailto:sage [2023/02/05(日) 18:32:46.51 ID:rtbv+KUs.net]: >>382
凄い納得
enum使わずにanyhow使うような連中はPythonでも使っていろ
anyhowなんてものがあるから勘違いが起こる
387 名前：デフォルトの名無しさん mailto:sage [2023/02/05(日) 20:10:29.95 ID:QsKcw+fO.net]: cargo crateのコード見てみた
anyhowを使ってエラーを上へ上げていく
enumを使っておらずエラーの網羅性はない
downcast_refを使ってエラー分岐している
388 名前：デフォルトの名無しさん mailto:sage [2023/02/05(日) 20:38:51.85 ID:1L9Nz43N.net]: エラーなんて作成時点で未知のものが後から増えることもザラだし
何なら抽象レイヤー以下の実装の差し替え（ストレージのネットワーク化とか）で
動的に増えたりすることもあるんだから、網羅性とかすぐ成り立たなくなる。
可能なところで逃すものじゃないけど、こだわるものでもない。
389 名前：デフォルトの名無しさん mailto:sage [2023/02/05(日) 21:15:55.10 ID:yQ5U4c14.net]: cargo みたいに手元や CI で実行するツールのエラー処理なんてその程度で十分ってこった。

もちろん、網羅が必要な領域のコードじゃそんなエラーハンドリングのやりかたじゃあ駄目だろうよ。
390 名前：デフォルトの名無しさん mailto:sage [2023/02/05(日) 21:31:31.79 ID:kVul7/Hf.net]: 多数の下部ライブラリから色んなエラーが上がってくるreqwestはそれらをdyn std::error::Errorへ入れているね
そしてdowncast_refで必要な分岐をして処理しているね
エラー処理はこれで十分でしょ
網羅しなくても残りは最終的にちゃんとエラー表示されるのだから
391 名前：デフォルトの名無しさん mailto:sage [2023/02/05(日) 22:59:47.83 ID:cfofmdL5.net]: エラー処理で必須な網羅性とはenumの網羅性とは異なる
いつどこでどんなエラーが発生しても必ず処理されることがエラー処理の網羅性
つまりエラー処理されないまま通常処理に進まないことでありRustではResultの利用によりそれが保証されている
したがってdyn Errorを使って一部をダウンキャストによりエラー処理し残りをエラー表示処理でも網羅性を満たしている
392 名前：デフォルトの名無しさん mailto:sage [2023/02/05(日) 23:51:35.27 ID:BjcIBdbF.net]: opaqueなerror typeを使うメリットは何なのか？デメリットは何なのか？
少なくともreqwestの開発者はそのトレードオフを検討した上で判断を下している

メリットもデメリットも理解できてないやつが珍説唱えても虚しいだけだぞ
393 名前：デフォルトの名無しさん mailto:sage [2023/02/05(日) 23:54:47.07 ID:arvSMdBl.net]: >>391
おまえはエクストリームな言い訳並べ立てる前にnon_exhaustiveの意味から調べろな
394 名前：デフォルトの名無しさん mailto:sage [2023/02/05(日) 23:58:58.86 ID:QsKcw+fO.net]: >>391
やっぱりそれでいいのか
Rustの標準IOライブラリはenumを使っているけどnon_exhaustive指定がしてありenumの網羅性チェックをむしろ使えないようにしてる
395 名前：デフォルトの名無しさん mailto:sage [2023/02/06(月) 00:09:01.18 ID:ZXNgtENY.net]: >>391
一般的なエラー処理の網羅性はその解釈だな
Rustでは型システムと返り型Result及びResult放置をコンパイラが警告してくれるため必ず網羅される仕組み
396 名前：デフォルトの名無しさん mailto:sage [2023/02/06(月) 01:23:09.90 ID:Kt6dB8yb.net]: >>394
non_exhaustive指定があると
なぜenumの網羅性チェックが使えないの？
397 名前：デフォルトの名無しさん mailto:sage [2023/02/06(月) 06:52:59.94 ID:OJBoAdFu.net]: 逆だよ
網羅性の扱いを禁止するために意図的にnon_exhaustive指定されている
そのようなエラーの種類には網羅性は必要がないだけでなく
今後もしエラーの種類が増えた場合に全網羅列挙して使用している既存のコードがエラーとなってしまう
そのためこういう時は不要である網羅性の扱いを禁止して全列挙コードを書かせないことで
今後エラーの種類が増えても既存の利用コードに影響を与えずに済む仕組み
398 名前：デフォルトの名無しさん mailto:sage [2023/02/06(月) 12:30:43.08 ID:wr+6RDlb.net]: >>397
自信満々に間違った情報を中身のない文章で膨らませてもっともらしく見せようとするところがChatGPTそっくりww
399 名前：デフォルトの名無しさん mailto:sage [2023/02/06(月) 12:48:04.84 ID:/nZ/7Knj.net]: 昔ながらの例外論争見てるみたいだ
全部取ればいいいや個別だ
400 名前：デフォルトの名無しさん mailto:sage [2023/02/06(月) 14:14:21.50 ID:C/yeK4bx.net]: >>397で合っているけど補足すれば
全網羅列挙コードを書いてもコンパイラがそれを許さずエラーとなる
全網羅列挙しなくていいから必ず全マッチの　_ =>　アームをコンパイラが要求してくる
つまりコンパイラによるエラーの網羅性チェックは不可能
401 名前：デフォルトの名無しさん mailto:sage [2023/02/06(月) 21:51:09.46 ID:MJNtWgHJ.net]: そもそもRust以前に他のプログラミング言語でもそのようなエラーの種類の網羅が行なわれたことはない
IOエラーだけでも何十種類もあり列挙するだけでも大変で意味のない作業
エラー処理で必要とされる網羅性とはエラーの種類を全て列挙することではなく
>>391の説明が正しい
RustでResultを使えば保証される
402 名前：デフォルトの名無しさん mailto:sage [2023/02/06(月) 21:59:33.19 ID:T23InEdz.net]: 自分の書いたレスを正しい正しいと
一人で連呼してて虚しくならないのかな
403 名前：デフォルトの名無しさん mailto:sage [2023/02/06(月) 22:26:04.02 ID:7y0OcpN0.net]: エラー処理の網羅性という話は元々
関数からエラー値が返って来る可能性があるのに見落として処理せずに続行しちゃったり
あるいは例外が返って来る可能性があるのに見落として処理しないままでいたり
そういう見落としがよく起きていたから
いつどこでどんなエラー(or例外)が起きても処理漏れがないようにプログラミングしましょうという話

もちろんRustではResultで返せばコンパイル時点でエラーや警告が出るためエラー処理の網羅性は満たされます
Resultを返していればdyn Errorやanyhowを使っていてももちろん大丈夫
そしてエラー処理の分岐にそれらのダウンキャストを使うのも何ら問題なし
404 名前：デフォルトの名無しさん [2023/02/07(火) 02:02:21.05 ID:smEuFI89.net]: anyhow使ってて困ったことないので、これからもanyhow使いますね
405 名前：デフォルトの名無しさん mailto:sage [2023/02/07(火) 02:09:15.61 ID:2blGAjQQ.net]: enumで網羅派の完全敗北だな
anyhowやdyn Errorでdowncast_ref分岐して何ら困らない
406 名前：デフォルトの名無しさん mailto:sage [2023/02/07(火) 02:13:05.33 ID:fMWAnbF1.net]: anyhowは邪道だろ
407 名前：デフォルトの名無しさん mailto:sage [2023/02/07(火) 10:30:33.69 ID:jDwZWgRX.net]: 下手に分かったふりせず疑問をぶつけるパニック君のようなレスはスレにとっては有益
逆に知ったかぶりして嘘を撒き散らす某オジのレスは害しかない

一緒に仕事してても伸びるのは断然前者のタイプ
後者は多少知識があってもチームの足を引っ張る老害タイプ
408 名前：デフォルトの名無しさん mailto:sage [2023/02/07(火) 11:56:13.05 ID:Yu/MJcLX.net]: >>407
知ったかぶりもだけど
ご飯論法的に毎回論点を捻じ曲げてくるのが悪質
スルー推奨
409 名前：デフォルトの名無しさん mailto:sage [2023/02/07(火) 12:39:13.84 ID:GmLWJf7C.net]: どの言語を使っていようがテスト設計とエラー処理設計は初心者と脱初心者を見分けるリトマス試験紙
チュートリアルやリファレンス読むだけでは身につかない
410 名前：デフォルトの名無しさん mailto:sage [2023/02/07(火) 13:41:38.43 ID:vPUoP0i3.net]: そう、IT土方必修
411 名前：デフォルトの名無しさん mailto:sage [2023/02/07(火) 20:09:18.77 ID:RZZKb5qe.net]: >>410
こういうバカが一人でも入ってくると現場は苦労するわな
412 名前：デフォルトの名無しさん mailto:sage [2023/02/07(火) 22:03:06.31 ID:u8XyY9YO.net]: 今回のケースはRustのエラー処理を他の言語（C#あたり）の例外処理に寄せようとしてる感じ
「特定の例外クラスをcatchしたい」→「dyn Errorで投げてダウンキャストで分岐すればいい」みたいな
anyhowはそういう人のためにあるのかもしれない

オブジェクト指向言語専攻の人はRustのtraitを基底クラスの代わりに使いがちだよね
is-a継承はRustだとenumで表現できる場合が多いんだけど切り替えが難しいのかも
413 名前：デフォルトの名無しさん mailto:sage [2023/02/07(火) 22:27:27.04 ID:23ICgzsB.net]: 単純にエラーの種類を列挙する意味がないときに使うだけやで
414 名前：デフォルトの名無しさん mailto:sage [2023/02/07(火) 23:09:28.73 ID:u8XyY9YO.net]: それならいいんだけど型キャストしてまで分岐するとか言ってる人がいたから
自分で分岐する範囲くらいは自分で列挙しとけって話
415 名前：デフォルトの名無しさん mailto:sage [2023/02/07(火) 23:53:31.04 ID:23ICgzsB.net]: 下層から上がってくる99種類のエラーはログ吐かせるだけで、特別な処理したいエラーはひとつしかないのにいちいちenumに詰め直したりせんわな
416 名前：デフォルトの名無しさん mailto:sage [2023/02/08(水) 00:04:28.76 ID:mV68xos2.net]: 逆
自分で分岐してエラー処理すんなら区別すべきエラーを決めるのは自分なのでanyhowやdyn Errorでダウンキャストしても問題ない

外から呼び出されるコードなら区別して処理するエラーを決めるのは呼び出し側なので区別できるようにenumで書く
417 名前：デフォルトの名無しさん [2023/02/08(水) 00:35:28.79 ID:ydIblX/+.net]: すまんが、これってなんでダメなの？
ブロックの最後に式を書いてるのに、なんでreturnって書かないとリターンしないの？？？
そもそもエラーの内容に書いてあるmismatched typesって、一体何と何のタイプがミスマッチなんなんだ・・・・
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=d1833710038ed821593015e5382de11f
エロい人教えて！！！
418 名前：デフォルトの名無しさん mailto:sage [2023/02/08(水) 01:51:02.48 ID:U3de6tMw.net]: >>417
else句が無いのでifの条件式がfalseの場合はif-expressionは()になるけど
ifの条件式がtrueの場合はif-expressionがi32になるのでミスマッチ
419 名前：デフォルトの名無しさん mailto:sage [2023/02/08(水) 01:59:22.59 ID:W8WwzKcT.net]: >>415
ログを吐かせるだけでもエラーによってログの吐き方を変えたいこともよくある話なのでケースバイケース
99種類を2種類に詰め直して片方をerased typeにしたりする
420 名前：デフォルトの名無しさん mailto:sage [2023/02/08(水) 07:28:48.49 ID:2c2bFNHO.net]: 上位の関数でもかなり多数のケースに分けてエラー処理する必要な場合だと
個別にenumにエラー型を収容する方が有利なケースもある
もちろんその場合でもanyhowやdyn Errorに収容してダウンキャストしてもよい
enum matchとダウンキャストの実行時コストはほぼ同じで優劣はなく視認性も変わらない
enumを使うとコードが増える問題はあるがあとは好みの問題
421 名前：デフォルトの名無しさん mailto:sage [2023/02/08(水) 10:45:01.05 ID:ENpYrX9l.net]: ダウンキャストは下位モジュールに不必要に依存することになるので選択の余地があるなら基本的には使うべきではない

自crateで定義したエラー型にダウンキャストするくらいならエラーを定義するついでにenum書いとけばいいだけ
他crateで定義したエラー型にダウンキャストしてるとバージョンアップ時にサイレントにキャストが失敗して動作が変わる

あくまで非常口であって使わざるをえないときはマイナス面を理解した上で注意深く使うもの

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

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