Rust part19

**デフォルトの名無しさん** · 2023/01/17(火) 12:41:32.25

公式
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/

**デフォルトの名無しさん** · 2023/02/01(水) 08:30:01.09

>>283
むしろ>>270の二点をサポートしているRustは開発効率が高いでしょう
それらをサポート出来ていない従来のプログラミング言語は開発効率も信頼性も低いわけです
開発効率と実行効率と信頼性の高さを両立させたRustの地位は揺るぎないと思われます

**デフォルトの名無しさん** · 2023/02/01(水) 08:37:05.02

ダックタイプ系の開発効率を求めるならRustは選択すべきじゃないよね。メモリの取り扱い見ればRustは「作法を強制する言語」だということは明らか。
そういうのはPythonとかRubyとかスクリプト言語があるんだからそっちを選ぶべき。

**デフォルトの名無しさん** · 2023/02/01(水) 08:41:21.89

>> 279
> 強い保証の意味がよくわからんが自前でキャッチして処理すれば良くね？
他は既に突っ込まれてるから言わんが
例外に関するプログラミングしてたらすぐにわかる概念だからググれ
つうか例外安全って言葉使うなら知っとけ

**デフォルトの名無しさん** · 2023/02/01(水) 08:54:40.02

>>285
例えばprintfみたいな関数で下位の例外を処理するのか？
処理するとして何をやるんだ？
って話
考え方が逆なの、自分に関与しない例外は触らない

>>286
ライブラリならドキュメントに書いてあるでしょ

>>287
また呪文唱え始めたのかw
せめてこれに答えてよ
> そもそも最下位の関数に新しいエラーが定義されたらrust使いは全部調べ直すのか？

**デフォルトの名無しさん** · 2023/02/01(水) 08:55:45.56

>>289
> 例外に関するプログラミングしてたらすぐにわかる概念だからググれ
また無能のググれかよw
答えられないなら無駄に絡んでくるなよ

**デフォルトの名無しさん** · 2023/02/01(水) 08:58:06.40

>>290
別に調べ直す必要はないよ
下位にエラーが追加されても直接呼び出す関数のシグネチャが変わらないなら対応不要、変わったら対応するってだけ
結局呼び出す関数のResult型が対応すべきもののすべてなんだからそれ以外見る必要がない

**デフォルトの名無しさん** · 2023/02/01(水) 09:02:33.17

>>288
そういうCPUもメモリも浪費するエコでない言語との比較はほとんど意味がないんじゃないかな
GC言語であってもそこそこ速いJavaやGoくらいの立ち位置の言語ならば比較の意味があるとしても

**デフォルトの名無しさん** · 2023/02/01(水) 09:20:03.74

>>290
> そもそも最下位の関数に新しいエラーが定義されたらrust使いは全部調べ直すのか？

Rustでそんなことをする必要がないよ
元々他のエラーも返す関数だったならば返り値型が元々Result型だから枠組みは変化なし
新たにエラーを返すように返り値型が変わったならばコンパイルエラーで気付く

**デフォルトの名無しさん** · 2023/02/01(水) 09:26:13.19

fishシェルをRustで書き直すことが（ほぼ）決まったよ
https://github.com/fish-shell/fish-shell/pull/9512

C++ と CMakeをかなり腐してるけど意外に荒れてない
ちなみに提案者は開発リーダーなのでほぼ決まりでしょう
リンクされてる移行プランは他のプロジェクトでも参考になりそう

**デフォルトの名無しさん** · 2023/02/01(水) 12:36:36.73

>>292,294
> 元々他のエラーも返す関数だったならば返り値型が元々Result型だから枠組みは変化なし
なら、その新しいエラー（例えばディスクフルを検出してたが今回ディスクオフラインなんてエラーが追加された）の処理が抜けてないことはどうやってわかるんだ？
実行時にしかわからないなら例外と変わらん
むしろ途中の伝搬コードをいちいち書くのが面倒なだけだろ

**デフォルトの名無しさん** · 2023/02/01(水) 12:42:13.45

Elixir にも、try/rescue の例外があるけど、あまり使わない。
throw/catch, raise でも、例外の発生場所を関数の外側から内側へ移すだけ

try do
%{a: a} = map
{:ok, a}

rescue
MatchError -> {:error, ":a が無い"}
end

とは書かずに、パターンマッチで書くのがElixir流

case map do
%{a: a} -> {:ok, a}
_ -> {:error, ":a が無い"}
end

**297** · 2023/02/01(水) 12:45:24.97

>>297
修正。内側・外側が逆だった

>throw/catch, raise でも、例外の発生場所を関数の外側から内側へ移すだけ
throw/catch, raise でも、例外の発生場所を関数の内側から外側へ移すだけ

**デフォルトの名無しさん** · 2023/02/01(水) 14:01:39.16

>>296
それはResult<T,E>のEで返されるエラーenumのvariantが増えるだけ
んでvariantが増えればEをハンドルしてるところでexhaustiveに処理してなければコンパイルエラー

**デフォルトの名無しさん** · 2023/02/01(水) 14:08:16.76

>>282
>言いたいのは「似たようなエラーをまとめておいて、修正も一括で行う」のイメージだった。
これはResultのコレクションを返せばいい
例外のある言語でもこのケースは例外じゃなくエラー情報を貯めたオブジェクトを戻り値で返してエラーがあったかどうかをチェックして分岐するコードを書く
それと似たようなもの

>例えば「関数内で細切れでファイルに書き込んでいるとき、どこかで書き込みエラーが出たらロールバックしてログを取って再書き込みする」とか。
ロールバックする系の処理ならエラーを貯めずにエラーが一つ出た時点で中断するように作ったほうがいい

**デフォルトの名無しさん** · 2023/02/01(水) 15:31:55.23

脳死でdyn Error突っ込んでるやつです

**デフォルトの名無しさん** · 2023/02/01(水) 15:34:50.34

dyn Errorで受け取った後の活用法が分からん

**デフォルトの名無しさん** · 2023/02/01(水) 17:49:22.59

dyn Errorでできるのは

・print!とかwrite!でログ出力する
（ErrorトレイトにDebugとDisplayが内包されてるからちゃんと実装されてれば何か教えてくれる）

・source()で内部のdyn Errorを掘り起こす
（エラーの原因のエラーがあれば一緒にログ出力できる）

くらいだからログ出力以上の活用がしたいならそのためのError型を使わないといけない

**デフォルトの名無しさん** · 2023/02/01(水) 18:15:38.74

>>302
具体的なエラーの型で分岐させたいならダウンキャストが必要(The Bookにも書いてたはず)
エラーenumを定義してwrapしたものに変換(map_err)しておけばダウンキャストは不要
anyhowに組み合わせてthiserrorの#[from]や#[error(transparent)]を使うと楽にwrapできる

anyhow/thiserrorのやってることに最初から自力で辿り着くのは大変だから先に使ってみて必要な要素を学んだ方が早いよ

**デフォルトの名無しさん** · 2023/02/01(水) 19:06:46.56

>>303
dynはErrorに限らず自由に元へ戻せるよ
例えばstd::io::Errorを含むdyn Errorが返ってきた時

if let Some(io_err) = dyn_err.downcast_ref::<io::Error>() {
　match io_err.kind() {
　　io::ErrorKind::NotFound => {

このように細かいエラーハンドリングが可能

>>304
順序が逆だよ
まずは標準ライブラリ内で上記のようにdyn Errorを使ったり
あるいはdynを使わずにimpl From<MyError> for io::ErrorでMyErrorのEnumに格納する「?」時の自動変換を書いたり
それぞれ簡単で単純なパターンなのだから標準ライブラリで基礎を身に着けた上で自作や外部のライブラリを選ぶのがお勧め

**デフォルトの名無しさん** · 2023/02/01(水) 19:07:10.38

>>290
例外をサポートしているような言語なら、投げる例外を関数のインターフェイスとしてドキュメントに記載する。
Rustなら>>292

>考え方が逆なの、自分に関与しない例外は触らない

>290が>285 >286を理解できない無能だということは理解できた。
c++とかでライブラリ関数からドキュメントに無い例外を投げられた経験が無いんだろうな。おめでたい。

**デフォルトの名無しさん** · 2023/02/01(水) 19:18:58.38

単発無能認定おじさん

**デフォルトの名無しさん** · 2023/02/01(水) 19:27:56.01

>> ライブラリならドキュメントに書いてあるでしょ

ドキュメントは言語システムの一部ではないため
ミスで現実のコードとドキュメントが食い違っていることもあれば
ドキュメントは正しくても利用者が見落としてしまうこともある
大規模な開発になればなるほどミスや見落としが紛れ込むことは避けられない
特にエラー処理が済んでいるか未だなのかは致命的になりかねない

一方でRustは言語システムの中で下位関数からエラーが上がってくるか処理済か分かる
さらにResultが未処理のままだとRustコンパイラが指摘してくれる
言語システムとして少なくともこれらの機能を持つ言語へと今後は移行していくべき流れ

**デフォルトの名無しさん** · 2023/02/01(水) 21:57:57.91

>>305
>それぞれ簡単で単純なパターンなのだから
実装の簡単さやパターンの単純さが問題じゃないんだよ
Rustのエラー処理に必要な「それぞれ簡単で単純なパターン」を網羅的に知識として仕入れてRustのエラー処理はこうやってやるものだと自信を持って言えるようになるまでの学習効率の問題
anyhow/thiserrorはそのパターンを楽に使えるよう作られてるから「ああRustのエラー処理ってこうやればいいんだな」ってのが標準ライブラリ前提で学ぶより断然早く理解できる

**デフォルトの名無しさん** · 2023/02/01(水) 22:05:04.46

>>309
dynの取り扱いと「?」オペレータによる自動変換はRustの基本事項で必須の知識
もちろん標準ライブラリの中で完結して使えるしシンプル仕組みなのですぐ使えるようになる
この基本を習得せずに外部ライブラリへ行くことを勧めるのは基本知識を欠いた人を生み出してしまう愚かな行為

**デフォルトの名無しさん** · 2023/02/01(水) 22:25:39.32

>>310
もしかしてパターンってdyn Errorと?オペレータ使った自動変換の話だけなの？
それだけじゃRustで現実的にどうエラー処理を実装すべきかThe Book読み終えたくらいの人にはわかんないと思うよ

**デフォルトの名無しさん** · 2023/02/01(水) 22:59:41.62

>>311
エラー処理パターンは様々な方針があり
その前提知識としての共通の必須事項として今回のスレの流れで話が出て来ていたdynの取り扱いと?での自動変換の話を書いた

例えばあなたが出したanyhowはdyn Errorを扱う外部ライブラリの一種
anyhow::Errorから具体的な型を取り出すためには>>305で書いたdynの取り扱い知識が必須
この知識を知らないと細かいエラー分類が出来ずにエラー表示のみしか出来ない人になってしまう

もう一つあなたが出したthiserrorも?での自動変換を用いる外部ライブラリ(というかマクロ)の一種
>>305で示したFrom::from()による自動変換の基礎知識を欠いたままでは仕組みすら分からず魔法のように外部ライブラリを使うダメな人になってしまう
応用が効かないだけでなく利用していて何か問題にハマった時に基本知識がないと解決することもできない

**デフォルトの名無しさん** · 2023/02/02(木) 00:32:13.04

>>312
設計やプラクティスとしてのパターンのことを言ってたんだが君は言語機能のことをパターンと呼んでるみたいで噛み合ってないよね

dyn Errorや?オペレータ使ってinto経由で変換されるような基本的な機能面の知識はThe Bookにも書かれてるレベルだし多少分からなくてもリファレンス読めばいいだけの話
でもそれだけの知識でRust初心者がエラー周りの実践的な設計をできるようにはならないでしょ

**デフォルトの名無しさん** · 2023/02/02(木) 00:53:57.92

anyhow/thiserrorは最近出てきた新興ライブラリ
当然それまでは誰も使っていなかったわけで初心者がいきなり必須なものでもない
初心者にとっては複雑で機能過多で理解しにくいのでまずは標準ライブラリから始めたほうが良いかな

**デフォルトの名無しさん** · 2023/02/02(木) 01:38:05.78

対象年齢付きのおもちゃか何か？w
自分だけ勝手に縛ってろw

**デフォルトの名無しさん** · 2023/02/02(木) 03:39:28.87

Rustは「教官付き教習車」だよ。
cとかと違ってアホが膝を撃ち抜く自由は許さない。
それが嫌ならRust止めれば？

**デフォルトの名無しさん** · 2023/02/02(木) 07:11:05.90

Rustはコンパイラの防波堤の中で安全な自由があるけどそれはともかく
クセの強いanyhowをRustの基本より先に初心者に教えるのはあかんよ
たとえば、他人も使うライブラリ作成ではanyhowの使用を避ける、といった当たり前のことも
エラーに関する基本を知らないと陥ってしまう

**デフォルトの名無しさん** · 2023/02/02(木) 07:31:00.57

>>316
rustの免許とりたいんですがおすすめの教習所はありますか？w

**デフォルトの名無しさん** · 2023/02/02(木) 07:34:23.41

anyhowはもはや標準ライブラリでしょ

**デフォルトの名無しさん** · 2023/02/02(木) 07:55:32.16

>>317
あれはクセというよりanyhowの致命的な欠陥だ
分かってる人は配慮して閉じた環境だけで使うけど稀に公開ライブラリにanyhow使っちゃう無知な人もいる
基礎知識はホント一番大事

**デフォルトの名無しさん** · 2023/02/02(木) 08:05:47.28

>>318
コンパイラ(教官)はひとつしか無いから選択肢は無いよ。

**デフォルトの名無しさん** · 2023/02/02(木) 08:14:13.18

コードを貼るわけでも実装例を示すわけでもない時点でシッタカだろ

**デフォルトの名無しさん** · 2023/02/02(木) 09:11:33.63

anyhow勧めてる人自身があんまり理解してないんだと思う

**デフォルトの名無しさん** · 2023/02/02(木) 12:40:03.75

複オジが使ったことないだけだろ
>>312も今調べてきました感満載じゃん
デファクトスタンダードになってるライブラリまで排除したらrustでは何もできんぞ

**デフォルトの名無しさん** · 2023/02/02(木) 12:47:49.51

オライリー本にも実戦ではanyhowとthiserrorを使えと書いてる

**デフォルトの名無しさん** · 2023/02/02(木) 12:59:53.51

>>321
うまいこといいますね。お見事！

**デフォルトの名無しさん** · 2023/02/02(木) 13:20:28.44

禁忌事項はライブラリを作って提供する時にanyhowを使ってしまうことだけだから
そこはanyhowを使わずにthiserrorを使えばヨシ

**デフォルトの名無しさん** · 2023/02/02(木) 15:47:50.42

別にanyhowをthiserrorに差し替えるのも大した手間じゃないしな
ライブラリで使っちゃってるなら変更PRでも出してやれば良い

**デフォルトの名無しさん** · 2023/02/02(木) 23:07:11.98

>>325
anyhowとthiserrorを使うなと言ってる人は誰もいなくて
・まず先にstd::error::Errorを覚えよう
・次に?変換とdynダウンキャストを覚えよう
・そしてanyhowとthiserrorへ進もう
という話でしょ
そうすればanyhowをライブラリで使うべきでない理由もわかるでしょうし

**デフォルトの名無しさん** · 2023/02/02(木) 23:14:43.66

Rustの世界でダウンキャストってなんかキモいな

**デフォルトの名無しさん** · 2023/02/02(木) 23:37:26.35

むしろRust基盤の一つ
downcastはエラー処理に限らずdyn Traitを元の型に戻すために必須
anyhowでも元のエラー型に戻すために必須

**デフォルトの名無しさん** · 2023/02/02(木) 23:53:43.61

ダウンキャストのソース見てみたら
やっぱりunsafeのかたまりだった

**デフォルトの名無しさん** · 2023/02/02(木) 23:53:52.64

ダウンキャストを知らないと
>>303のようにdyn Errorで出来ることはログ出力だけと思いこんでしまう

**デフォルトの名無しさん** · 2023/02/02(木) 23:59:01.23

>>332
当たり前
Rustの標準ライブラリはunsafeだらけ
原理的にunsafeは避けられないからそれを安全なインターフェイスとして公開するのがRustの標準ライブラリ

**デフォルトの名無しさん** · 2023/02/03(金) 00:57:17.44

dynを元の型に戻すという発想に違和感（気持ち悪さ）を感じる人もいると思う
元の型に戻すつもりならそもそもdynにしないというか
ダウンキャストは戻すべき型（の変更）を全部把握できる閉じた状況じゃないと使いにくい

**デフォルトの名無しさん** · 2023/02/03(金) 01:37:41.39

>>335
anyhowを使うのはそういう全部把握できる閉じた状況で
独自エラー型を用意するのが面倒な時に使うからダウンキャストが理に適っている
嫌ならanyhow使わずにthiserrorを使えばよい

**デフォルトの名無しさん** · 2023/02/03(金) 07:58:09.95

>>335
型を全て把握しておく必要はない
例えばエラー処理で大半はエラー表示のみだが一部だけ特別な処理をしたいとすると
その処理したいエラー型のみダウンキャストして使えばいい

ちなみにダウンキャストは内部で定数のu64で表現される型番号をu64比較するだけなのでコストがかかるものではない

**デフォルトの名無しさん** · 2023/02/03(金) 08:54:57.66

ダウンキャストの扱いかどうか知らんが、パターンマッチングも総和型から個別型ヘのキャストみたいなもんだろ。

**デフォルトの名無しさん** · 2023/02/03(金) 09:11:06.24

もしdyn使わずに自作Enum収容エラー型を定義して使っても
Enumタグ比較で分岐することになるから状況は似たようなもの

**デフォルトの名無しさん** · 2023/02/03(金) 09:18:29.47

std::any::Any.downcast_ref() を使わずにanyhow独自に実装してるね

**デフォルトの名無しさん** · 2023/02/03(金) 09:36:29.67

初めて間もないけど
println!("{}", a);
とか手が攣って辛い
tabでもprintlnまでしかでないしコピペでもしてるの？

**デフォルトの名無しさん** · 2023/02/03(金) 09:43:50.06

downcastすればいいだけだからdyn Error返してもデメリットは無いってのなら
ライブラリでanyhowを使うのも大した問題じゃないって結論になるん？

**デフォルトの名無しさん** · 2023/02/03(金) 10:26:25.61

>>342
anyhowの問題点はそこではない
anyhowは最も重要なことを実装していない(不可能)という欠点があるため

**デフォルトの名無しさん** · 2023/02/03(金) 10:31:15.17

>>343
anyhowの問題点なんて一般的じゃないんだから、曖昧に言わずに具体的に説明しなよ。

**デフォルトの名無しさん** · 2023/02/03(金) 10:48:35.31

予言しよう
ググれば分かるんだから書かないとか言って絶対に具体的な説明はしないやつだよ

**デフォルトの名無しさん** · 2023/02/03(金) 12:00:34.82

俺はなんも知らんから頭の片隅に覚えておくくらいにしとくわ
使うときに調べる

**デフォルトの名無しさん** · 2023/02/03(金) 12:23:43.68

>>345
検索しても出てこなかったよ。

**デフォルトの名無しさん** · 2023/02/03(金) 12:37:16.79

Rustでエラー型はstd::error::Errorトレイトを実装するのが共通のお約束だけど
anyhow::Errorは諸事情あって実装されていないんよ
std::error::Errorトレイト実装を前提として扱っているところへライブラリがanyhow::Errorを返しちゃうと困っちゃう
ライブラリを作るときはthiserrorでエラー型を作ればstd::error::Errorトレイトを自動で実装してくれるから大丈夫だよ
もちろんthiserror使わずに自分で実装してもいいよ

**デフォルトの名無しさん** · 2023/02/03(金) 15:29:10.83

>>348
「このライブラリはanyhow対応必須です。anyhow対応しないと使えません」
ならOKかね。

**デフォルトの名無しさん** · 2023/02/03(金) 18:59:27.03

Box<dyn Error>もErrorトレイト実装してないよ(コンフリクトで実装できない)
その点はdyn Errorで返してもanyhowで返しても大差ない
libraryのpublicなAPIでtype erasedなエラーを返したいときは
Errorを実装した独自のエラー型を用意するのが普通
anyhowで返してる有名ライブラリもあるけどね

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

なぜ同じ作者のエラー系のライブラリがanyhowとthiserrorと2つあるんだろうか？
と疑問に持つだけでも初心者はstdベースで学習するよりも1歩先に進めてる

**デフォルトの名無しさん** · 2023/02/04(土) 00:38:01.54

ダウンキャストは静的チェックできず変更に弱いからホイホイ使うものじゃないよ

**デフォルトの名無しさん** · 2023/02/04(土) 07:20:32.73

>>351
ダウンキャストは静的に型を指定して
Some()で静的な型で値が返ってきて
その値の使用も静的に型チェックされる

「マッチングが動的ではないか？」については
Enumで複数の型を収容した場合と全く同じ
どちらの場合もマッチングは動的に行われるが静的に型チェックされる
どちらも静的に型を抽象化した定数の整数値との比較によるマッチングとなる点も同じ

**デフォルトの名無しさん** · 2023/02/04(土) 09:46:17.84

ばかばかc

**デフォルトの名無しさん** · 2023/02/04(土) 09:59:08.11

Rustのdynとそのdowncastは安全性と最小限のコストを両立させており安心して使える
引数などでimpl Traitが使える場合はimplが有利なケースもあるが
返値などでdyn Traitしか使えない場合もあり適材適所で使い分け

**デフォルトの名無しさん** · 2023/02/04(土) 10:30:58.71

>>352
よくわかってないものを人に勧めちゃダメだよ

**デフォルトの名無しさん** · 2023/02/04(土) 12:22:28.04

久々に荒らし発生かな

**デフォルトの名無しさん** · 2023/02/04(土) 12:44:13.93

ダウンキャストの安全性みたいなのは downcast_ref 使ってりゃ議論の余地はないと思うけど網羅性は限界があるわね。

ライブラリはやっぱエラー型を明示すべき。

**デフォルトの名無しさん** · 2023/02/04(土) 13:10:09.04

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

**デフォルトの名無しさん** · 2023/02/04(土) 13:39:49.84

エラー処理で網羅性は関係ないだろ
std::io::Errorのenum ErrorKindからしてnon_exaustive指定だぞ
match式で網羅性はチェックされない
特別な処理が必要なエラーだけ処理対応して残りはエラー表示が普通だ

**デフォルトの名無しさん** · 2023/02/04(土) 13:52:58.01

エラー処理で重要なことは
・エラーが発生しているにも関わらずそのまま通常処理を進めないこと
・エラー表示以外の対応を必要とするエラーの場合にその対応をすること
・それ以外のエラーはエラー表示などをすること
enumタグレベルの網羅性を求められることはないな

**デフォルトの名無しさん** · 2023/02/04(土) 14:46:52.23

元々の話はdyn Errorかanyhowか、だったような気がするけど、
anyhowはdyn Errorの自作ラッピングみたいなもので、
とちらを使ってもダウンキャストしなきゃいけない点も網羅性がない点も同じだよね。
そしてそれらをアプリ側で使ってる限り困ることもない。

**デフォルトの名無しさん** · 2023/02/04(土) 17:06:34.73

そもそもがダックタイピングとか向いてる言語じゃない。
フロントでこの言語使おうとするとかただのバカでしかないわ。

**デフォルトの名無しさん** · 2023/02/04(土) 17:36:37.29

唐突にフロントとかダックタイピングとかどうした？
しかもその二つも関連性がない

**デフォルトの名無しさん** · 2023/02/04(土) 18:06:27.05

上位レイヤーも含めてエラーの内容によって分岐したいならdyn Errorはやめたほうがいい

**デフォルトの名無しさん** · 2023/02/04(土) 18:34:38.01

分岐にenumのタグを使うかErrorの型名を使うかの違いでしょ
enumを使うと一貫性を担保しやすいから保守性が向上するし
dyn Errorを使うとenumの定義を省略できるからコードを減らせる
自分は（分岐するなら）enum派だけど何を重視するかで結論が変わりそう
ただ「やることが一緒だからどっちも同じ」と考えはいただけない

**デフォルトの名無しさん** · 2023/02/04(土) 18:40:15.09

>>364
dyn Errorをやめるべき理由がない
まさかと思うが代わりにanyhow使えとか言い出すんじゃないんだろうな？

**デフォルトの名無しさん** · 2023/02/04(土) 19:00:20.00

dyn Errorもダウンキャストも使用して全く問題ないよ
有名どころでも普通に使われている
例えばreqwestはdyn Errorを使っていてdowncast_ref()してエラー処理している
cargoはanyhowを使っていてdowncast_ref()してエラー処理している
使うのをやめたほうがいいと主張している人は一種の宗教にすぎないことに気付こう

**デフォルトの名無しさん** · 2023/02/04(土) 22:40:19.42

勘違いしてる内容が同じだから
自演しまくっても同一人物なの丸分かりだね
ダウンキャストオジ==複オジ

**デフォルトの名無しさん** · 2023/02/05(日) 02:20:20.64

無敵やな
もちろんいい意味で

**デフォルトの名無しさん** · 2023/02/05(日) 02:25:01.54

一年ぐらい前にanyhowを標準化する、みたいな話なかったっけ？

**デフォルトの名無しさん** · 2023/02/05(日) 02:59:04.83

anyhowはダウンキャストするしかないクソ

**デフォルトの名無しさん** · 2023/02/05(日) 06:00:11.27

オライリーの本って出てから1年経つけどさあ
これの電子版って、セールになったりする機会ってあるもんなの？

**デフォルトの名無しさん** · 2023/02/05(日) 06:31:13.67

ダウンキャストを毛嫌いしてる人の心理を知りたい

**デフォルトの名無しさん** · 2023/02/05(日) 12:11:30.30

>>359-360
おまえはまるで何もわかってないのな
エラーハンドリングの基礎すらおさえてないじゃん
無知なのはいいが自信満々で嘘を書きまくるのはやめろ

**デフォルトの名無しさん** · 2023/02/05(日) 12:37:36.14

作るシステムの性質や分野ごとで許されるエラーハンドリングは別物だからね。
ミッションクリティカルだけが正解ってわけでもないのよ。

**デフォルトの名無しさん** · 2023/02/05(日) 14:02:09.96

>>375
何がまちがってるかさえも分からないようならThe Bookを一から読み直して出直してこい

**デフォルトの名無しさん** · 2023/02/05(日) 14:22:39.74

たまに出てくる「間違っている」「勘違いしてる」「嘘を書くな」の人
今までも文句をつけるだけで正確を書いたことがないから信頼できないのよね

**デフォルトの名無しさん** · 2023/02/05(日) 14:23:18.13

どっちも自分の脳内シチュでしか語ってないからふわっふわで論破出来るわけもなし
自分の主張が通る具体例上げるといいよ

**デフォルトの名無しさん** · 2023/02/05(日) 14:35:53.55

｢カッコウのアルゴリズムさえまともに実装できてないからクソ遅いんだよな｣
みたいに適当なワード混ぜて意味不明なこと言いつつ同意してる風を装うと｢そうなんだよ！｣とか勝手に乗っかってきて自爆するから面白いぞ

**デフォルトの名無しさん** · 2023/02/05(日) 15:42:56.66

>>377
それは信頼以前に、相手にしなくていい外野

>>379
すごく目に見えるわその展開ｗ

**デフォルトの名無しさん** · 2023/02/05(日) 15:53:21.98

>>373
台所まで行けば箸（enum）があるのに手元のフォークで焼きそばを食べてる感じ
食べてるのがパスタ（Python）なら平気なんだけど

**デフォルトの名無しさん** · 2023/02/05(日) 16:01:07.42

>>381
微妙にわかりにくい例えで草
でも複オジに比べると1000倍マシ

**デフォルトの名無しさん** · 2023/02/05(日) 16:04:59.96

>>377
信頼するかどうかはあなた次第
>>359-360が嘘だらけだということが分からない人は基礎がなってないから勉強やり直すかパスタにするか

**デフォルトの名無しさん** · 2023/02/05(日) 17:40:20.51

網羅性が必要ないならResult使う必要もRustを使う必要もないわな

**デフォルトの名無しさん** · 2023/02/05(日) 18:32:46.51

>>381
凄い納得
enum使わずにanyhow使うような連中はPythonでも使っていろ
anyhowなんてものがあるから勘違いが起こる

**デフォルトの名無しさん** · 2023/02/05(日) 20:10:29.95

cargo crateのコード見てみた
anyhowを使ってエラーを上へ上げていく
enumを使っておらずエラーの網羅性はない
downcast_refを使ってエラー分岐している