- 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/
- 256 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 19:51:16.79 ID:7I30yv0f.net]
- >>247
Rustは標準でスタックトレースをサポートとしている
何でもいいからコンパイルして実行したことあればRUST_BACKTRACE=1と環境変数をセットすれば出力すると表示されることすら知らないのは不思議
ちなみにstd::backtrace::Backtraceによって自由自在に好きなところでバックトレースをキャプチャすることも出来る
- 257 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 19:56:49.64 ID:7I30yv0f.net]
- >>251
Rustでもエラー処理を上位に委託してエラー処理を一箇所に局所化できる点は全く同じ
いくら初心者でもネット上のBOOKやサンプルや書籍など見てコードを書けばすぐに分かること
- 258 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 19:58:31.81 ID:iWzBLVlH.net]
- >>255
254じゃないけど、メリットは分かりやすいけどなぁ。
関数のインターフェイスに、関数の作用に関する情報がまとまっていたらそりゃ便利だろう。
例外を投げる関数の場合、例外に関する情報は関数のマニュアルを参照するかソースを参照するしかないことがほとんどじゃない？インターフェイスを見ただけで例外を把握できる言語てあったっけ？
- 259 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 20:06:28.07 ID:0vRdrBrN.net]
- ML系の系譜の言語はまあ大体そうなんじゃね
そしてRustでもdyn Errorで返されたら結局同じことやらされる羽目に……
- 260 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 20:17:47.02 ID:YNMDboNb.net]
- >>258
だから例外に関与しないのになぜそんな情報いるんだ？
- 261 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 20:25:27.93 ID:QTaicIN8.net]
- >>260
マジでそれ言ってるの？ マジで？
例外を無視しても「例外が投げられる」という作用は消えないよ？
例外が投げられても「俺関与しないから」と言って無視するの？
- 262 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 20:27:00.46 ID:1QZESm3t.net]
- 例外に関与しないってどういう意味なんだろう？
ガン無視するって言ってるんだろうか？
- 263 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 20:36:05.54 ID:YNMDboNb.net]
- >>261-262
いちいち曲解するなよ
下位で発生した例外は何もしなければそのまま上位に伝搬するだろ
例外安全に作られてればその関数で確保したリソースはちゃんと解放される
それは下位の例外の種類に依存しない
- 264 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 21:10:03.87 ID:QTaicIN8.net]
- >>263
「上位に伝達する」という意味わかっている？
>258がインターフェイスの話をしているのは理解できている？
関数の呼び出し元からすれば、呼び出し先で投げられているのか、さらにその先で投げられているのか、とか関係なく「関数を使ったら例外を投げられた」だよ。関数のユーザーからすれば「投げる例外くらい明確化するのが常識だろ」と思うよな。
関数が例外を投げるのに、その関数の作者が「例外に関与しないからオレ知らね」とか言って逃げたらブチ切れるわ。そんなんだったら例外全部catchして関数の外に漏らすな、と。
- 265 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 21:16:22.90 ID:1QZESm3t.net]
- >>263
例外安全って意味広すぎて
強い保証したいときとかあるやろ
- 266 名前：デフォルトの名無しさん [2023/01/31(火) 21:28:25.11 ID:Qz/Q1rYV.net]
- Javaの検査/非検査例外以降の約20年余りの試行錯誤の結果辿り着いた現時点でのベストプラクティスを採用したのがRustやSwiftのエラー処理モデル
C → Java → C# → Go →Swift/Rust
- 267 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 21:35:24.95 ID:Mxurit6u.net]
- >>263
そうやって
ヌルポで落ちるプログラムを量産したんだよね
- 268 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 21:42:42.48 ID:QTaicIN8.net]
- まぁ、Result使うとしてもtry catch finallyブロックみたいなフローが欲しいというのはわからんでもない。
関数から抜ける時にResultを漏らさず処理したいというのはたまにあるし。
- 269 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 21:48:12.48 ID:jD2BQUnk.net]
- >>263
catchとかしないの？回復処理したり付加情報付きの例外投げ直したり
そのためにはcatchすべき例外が上がってくるかどうか知らないといけないんだけど
- 270 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 22:04:35.47 ID:WaCEL3Yw.net]
- この件でプログラミング言語が最低限サポートして欲しい点2つ
ある関数(ライブラリ)を使おうとした時に
①その関数やその子孫からエラーや例外が上がってくるのか、それとも全て処理済なのか？
これが奥深く辿らなくても局所的に把握できること
ドキュメントベースはそのミスや見落としが生じるため不可
②エラーや例外が下から上がってくる関数を用いた時に、
その処理をせずに続行してしまうコードを書いてしまったら、実行前に言語システムにより防げること
例えばRustならば①は返値がResult型かどうかですぐに把握できる
②は型システムによりRustコンパイラが型不一致や未処理放置Resultの存在を伝えてくれる
Rustは現在ベストなプログラミング言語と言い切っても過言ではない
- 271 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 22:16:44.29 ID:Mxurit6u.net]
- >>270
高い信頼性が要求されないプログラムなら
例外と集約エラーハンドラさえあればいいんだから
Rust的なモデルが最適化どうかは要件次第だよ
結局はトレードオフ
- 272 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 22:19:53.43 ID:Mxurit6u.net]
- >>268
今でもResultを漏らさず処理できると思うんだけど
できないのってどういう状況？
- 273 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 22:45:41.29 ID:WaCEL3Yw.net]
- >>271
趣味のおもちゃプログラムでなければ信頼性は必須だよね
それだけでなく>>270の最低限の2点はプログラマーにとっても必要なこと
①を満たせない言語では無駄に調べまくらなければいけない
②を満たせない言語では無駄に実行時デバッグを強いられる
トレードオフと言われても信頼性と開発効率を両方落とすのは割に合わない
- 274 名前：デフォルトの名無しさん [2023/01/31(火) 23:47:23.84 ID:ovWek0QN.net]
- 使いたい関数だけじゃなくて、その関数が使ってる関数、更にその関数が、、、って調べていかないといけないのが無駄にコスト高になるんだよね。
- 275 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 23:54:22.59 ID:hwxs0+db.net]
- >>274
使いたい関数のシグニチャ見れば分かることだろ？？？？？
- 276 名前：デフォルトの名無しさん [2023/02/01(水) 00:33:02.66 ID:CK4ZTpUy.net]
- やっぱ複オジは成長しねーな
2世と同類だわ
- 277 名前：デフォルトの名無しさん mailto:sage [2023/02/01(水) 03:40:06.80 ID:RyGmTTdX.net]
- >>275
それが正しいか信頼できんだろ
- 278 名前：デフォルトの名無しさん mailto:sage [2023/02/01(水) 06:17:22.82 ID:5NtLPUR3.net]
- >>275
Rustならば使う関数のシグネチャを見ればResultが返ることで>>270の①を知ることができるけど
例外機構の言語の多くはシグネチャには情報がないため完全に信頼できるドキュメントでもない限り下流の関数全調査になるかな
②の処理忘れ防止機能も含めてRustが最も整備されている言語という感じ
- 279 名前：デフォルトの名無しさん mailto:sage [2023/02/01(水) 07:12:22.77 ID:Hf88nfPH.net]
- >>264
だから上がってくる例外を処理する必要があるならその時に調べればいいでしょ？
例えばprintfみたいな関数作ってる時に下位のputsみたいな関数がI/Oエラーで例外上げてくるだろうけどそれはそのまま上位にあげるだけだろ
いちいち意識する必要はない
>>265
強い保証の意味がよくわからんが自前でキャッチして処理すれば良くね？
>>269
全ての関数で回復処理が必要なわけじゃないし情報を付加するだけなら例外の種類を問わずにキャッチしてスローすればいいでしょ
すべての階層で事細かく例外をキャッチしてスローし直すなんてことは普通やらないよ
- 280 名前：デフォルトの名無しさん mailto:sage [2023/02/01(水) 07:21:02.47 ID:Hf88nfPH.net]
- >>270
言いたいことはわかるけどそれを実現する手間が掛かりすぎると思う
そもそも例外を上げるかどうかだけを見たいならnoexceptを真面目に実装すればいいだけだし
- 281 名前：デフォルトの名無しさん mailto:sage [2023/02/01(水) 08:02:53.27 ID:5NtLPUR3.net]
- >>280
それを実現する手間が掛かりすぎる、という視点がむしろ既に間違えているのかもね
従来の例外の枠組みを持たずにRustは>>270の二点をシンプルで効率よく実現してしまった
つまり従来の例外の枠組みよりも利便性と信頼性の高い新たな枠組みが実用的だと示されたのだから
従来の例外の枠組みを捨てるべき時が訪れたと解釈する方が正しいのかもしれない
- 282 名前：デフォルトの名無しさん mailto:sage [2023/02/01(水) 08:17:31.54 ID:rokbXrwB.net]
- >>272
あ、漏らさず処理はできるな。ごめん。
言いたいのは「似たようなエラーをまとめておいて、修正も一括で行う」のイメージだった。
例えば「関数内で細切れでファイルに書き込んでいるとき、どこかで書き込みエラーが出たらロールバックしてログを取って再書き込みする」とか。
>>279
やっぱり全然理解できていないな。
その「printfみたいな関数」を使う「上位」のプログラマーはどうすんだよ。「例外に関与しないからオレ知らね」か？
そんなんだったら例外全部catchして関数の外に漏らすな。
- 283 名前：デフォルトの名無しさん mailto:sage [2023/02/01(水) 08:17:38.20 ID:Hf88nfPH.net]
- >>281
> 従来の例外の枠組みを持たずにRustは>>270の二点をシンプルで効率よく実現してしまった
シンプルだけど生産効率は良くないよね？
って言ってるんだけど...
- 284 名前：デフォルトの名無しさん mailto:sage [2023/02/01(水) 08:20:02.84 ID:Hf88nfPH.net]
- >>282
上位で処理する必要があるならその時に調べればいいだろ
途中の関数で逐一調べる必要はない
そもそも最下位の関数に新しいエラーが定義されたらrust使いは全部調べ直すのか？
- 285 名前：デフォルトの名無しさん mailto:sage [2023/02/01(水) 08:25:05.41 ID:ATJMUMOg.net]
- >>279
その調べるかどうかをどう判断するかって話なんだが…
putsがI/Oエラーを上げてくるって知ってるから無視して上に上げるって判断ができるわけ
じゃあライブラリXの関数Yは無視すべきなのかそうでないのか？ってこと
- 286 名前：デフォルトの名無しさん mailto:sage [2023/02/01(水) 08:27:52.62 ID:rokbXrwB.net]
- >>284
どうやって調べるのか、具体的に考えた？
インターフェイスしか提供されていなくて、ソースコードの無いライブラリとかでどうやって調べるの？
エスパーか神様でもなければ不可能だね。
- 287 名前：デフォルトの名無しさん mailto:sage [2023/02/01(水) 08:30:01.09 ID:5NtLPUR3.net]
- >>283
むしろ>>270の二点をサポートしているRustは開発効率が高いでしょう
それらをサポート出来ていない従来のプログラミング言語は開発効率も信頼性も低いわけです
開発効率と実行効率と信頼性の高さを両立させたRustの地位は揺るぎないと思われます
- 288 名前：デフォルトの名無しさん mailto:sage [2023/02/01(水) 08:37:05.02 ID:rokbXrwB.net]
- ダックタイプ系の開発効率を求めるならRustは選択すべきじゃないよね。メモリの取り扱い見ればRustは「作法を強制する言語」だということは明らか。
そういうのはPythonとかRubyとかスクリプト言語があるんだからそっちを選ぶべき。
- 289 名前：デフォルトの名無しさん mailto:sage [2023/02/01(水) 08:41:21.89 ID:wznv5J1H.net]
- >> 279
> 強い保証の意味がよくわからんが自前でキャッチして処理すれば良くね？
他は既に突っ込まれてるから言わんが
例外に関するプログラミングしてたらすぐにわかる概念だからググれ
つうか例外安全って言葉使うなら知っとけ
- 290 名前：デフォルトの名無しさん mailto:sage [2023/02/01(水) 08:54:40.02 ID:Hf88nfPH.net]
- >>285
例えばprintfみたいな関数で下位の例外を処理するのか？
処理するとして何をやるんだ？
って話
考え方が逆なの、自分に関与しない例外は触らない
>>286
ライブラリならドキュメントに書いてあるでしょ
>>287
また呪文唱え始めたのかw
せめてこれに答えてよ
> そもそも最下位の関数に新しいエラーが定義されたらrust使いは全部調べ直すのか？
- 291 名前：デフォルトの名無しさん mailto:sage [2023/02/01(水) 08:55:45.56 ID:Hf88nfPH.net]
- >>289
> 例外に関するプログラミングしてたらすぐにわかる概念だからググれ
また無能のググれかよw
答えられないなら無駄に絡んでくるなよ
- 292 名前：デフォルトの名無しさん mailto:sage [2023/02/01(水) 08:58:06.40 ID:ATJMUMOg.net]
- >>290
別に調べ直す必要はないよ
下位にエラーが追加されても直接呼び出す関数のシグネチャが変わらないなら対応不要、変わったら対応するってだけ
結局呼び出す関数のResult型が対応すべきもののすべてなんだからそれ以外見る必要がない
- 293 名前：デフォルトの名無しさん mailto:sage [2023/02/01(水) 09:02:33.17 ID:JRuvbVor.net]
- >>288
そういうCPUもメモリも浪費するエコでない言語との比較はほとんど意味がないんじゃないかな
GC言語であってもそこそこ速いJavaやGoくらいの立ち位置の言語ならば比較の意味があるとしても
- 294 名前：デフォルトの名無しさん mailto:sage [2023/02/01(水) 09:20:03.74 ID:JRuvbVor.net]
- >>290
> そもそも最下位の関数に新しいエラーが定義されたらrust使いは全部調べ直すのか？
Rustでそんなことをする必要がないよ
元々他のエラーも返す関数だったならば返り値型が元々Result型だから枠組みは変化なし
新たにエラーを返すように返り値型が変わったならばコンパイルエラーで気付く
- 295 名前：デフォルトの名無しさん mailto:sage [2023/02/01(水) 09:26:13.19 ID:ypE1x0h9.net]
- fishシェルをRustで書き直すことが（ほぼ）決まったよ
https://github.com/fish-shell/fish-shell/pull/9512
C++ と CMakeをかなり腐してるけど意外に荒れてない
ちなみに提案者は開発リーダーなのでほぼ決まりでしょう
リンクされてる移行プランは他のプロジェクトでも参考になりそう
- 296 名前：デフォルトの名無しさん mailto:sage [2023/02/01(水) 12:36:36.73 ID:o2DBVRIO.net]
- >>292,294
> 元々他のエラーも返す関数だったならば返り値型が元々Result型だから枠組みは変化なし
なら、その新しいエラー（例えばディスクフルを検出してたが今回ディスクオフラインなんてエラーが追加された）の処理が抜けてないことはどうやってわかるんだ？
実行時にしかわからないなら例外と変わらん
むしろ途中の伝搬コードをいちいち書くのが面倒なだけだろ
- 297 名前：デフォルトの名無しさん mailto:sage [2023/02/01(水) 12:42:13.45 ID:BH4poKX+.net]
- 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
- 298 名前：297 mailto:sage [2023/02/01(水) 12:45:24.97 ID:BH4poKX+.net]
- >>297
修正。内側・外側が逆だった
>throw/catch, raise でも、例外の発生場所を関数の外側から内側へ移すだけ
throw/catch, raise でも、例外の発生場所を関数の内側から外側へ移すだけ
- 299 名前：デフォルトの名無しさん [2023/02/01(水) 14:01:39.16 ID:TUW+NsdV.net]
- >>296
それはResult<T,E>のEで返されるエラーenumのvariantが増えるだけ
んでvariantが増えればEをハンドルしてるところでexhaustiveに処理してなければコンパイルエラー
- 300 名前：デフォルトの名無しさん [2023/02/01(水) 14:08:16.76 ID:w5pt5x/h.net]
- >>282
>言いたいのは「似たようなエラーをまとめておいて、修正も一括で行う」のイメージだった。
これはResultのコレクションを返せばいい
例外のある言語でもこのケースは例外じゃなくエラー情報を貯めたオブジェクトを戻り値で返してエラーがあったかどうかをチェックして分岐するコードを書く
それと似たようなもの
>例えば「関数内で細切れでファイルに書き込んでいるとき、どこかで書き込みエラーが出たらロールバックしてログを取って再書き込みする」とか。
ロールバックする系の処理ならエラーを貯めずにエラーが一つ出た時点で中断するように作ったほうがいい
- 301 名前：デフォルトの名無しさん mailto:sage [2023/02/01(水) 15:31:55.23 ID:4CkJdapD.net]
- 脳死でdyn Error突っ込んでるやつです
- 302 名前：デフォルトの名無しさん mailto:sage [2023/02/01(水) 15:34:50.34 ID:ypE1x0h9.net]
- dyn Errorで受け取った後の活用法が分からん
- 303 名前：デフォルトの名無しさん mailto:sage [2023/02/01(水) 17:49:22.59 ID:HDxpsRMp.net]
- dyn Errorでできるのは
・print!とかwrite!でログ出力する
（ErrorトレイトにDebugとDisplayが内包されてるからちゃんと実装されてれば何か教えてくれる）
・source()で内部のdyn Errorを掘り起こす
（エラーの原因のエラーがあれば一緒にログ出力できる）
くらいだからログ出力以上の活用がしたいならそのためのError型を使わないといけない
- 304 名前：デフォルトの名無しさん [2023/02/01(水) 18:15:38.74 ID:pHJayYFi.net]
- >>302
具体的なエラーの型で分岐させたいならダウンキャストが必要(The Bookにも書いてたはず)
エラーenumを定義してwrapしたものに変換(map_err)しておけばダウンキャストは不要
anyhowに組み合わせてthiserrorの#[from]や#[error(transparent)]を使うと楽にwrapできる
anyhow/thiserrorのやってることに最初から自力で辿り着くのは大変だから先に使ってみて必要な要素を学んだ方が早いよ
- 305 名前：デフォルトの名無しさん mailto:sage [2023/02/01(水) 19:06:46.56 ID:JRuvbVor.net]
- >>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に格納する「?」時の自動変換を書いたり
それぞれ簡単で単純なパターンなのだから標準ライブラリで基礎を身に着けた上で自作や外部のライブラリを選ぶのがお勧め
- 306 名前：デフォルトの名無しさん mailto:sage [2023/02/01(水) 19:07:10.38 ID:sE34HuOS.net]
- >>290
例外をサポートしているような言語なら、投げる例外を関数のインターフェイスとしてドキュメントに記載する。
Rustなら>>292
>考え方が逆なの、自分に関与しない例外は触らない
>290が>285 >286を理解できない無能だということは理解できた。
c++とかでライブラリ関数からドキュメントに無い例外を投げられた経験が無いんだろうな。おめでたい。
- 307 名前：デフォルトの名無しさん mailto:sage [2023/02/01(水) 19:18:58.38 ID:RjOpz7Dl.net]
- 単発無能認定おじさん
- 308 名前：デフォルトの名無しさん mailto:sage [2023/02/01(水) 19:27:56.01 ID:JRuvbVor.net]
- >> ライブラリならドキュメントに書いてあるでしょ
ドキュメントは言語システムの一部ではないため
ミスで現実のコードとドキュメントが食い違っていることもあれば
ドキュメントは正しくても利用者が見落としてしまうこともある
大規模な開発になればなるほどミスや見落としが紛れ込むことは避けられない
特にエラー処理が済んでいるか未だなのかは致命的になりかねない
一方でRustは言語システムの中で下位関数からエラーが上がってくるか処理済か分かる
さらにResultが未処理のままだとRustコンパイラが指摘してくれる
言語システムとして少なくともこれらの機能を持つ言語へと今後は移行していくべき流れ
- 309 名前：デフォルトの名無しさん [2023/02/01(水) 21:57:57.91 ID:qgBIsers.net]
- >>305
>それぞれ簡単で単純なパターンなのだから
実装の簡単さやパターンの単純さが問題じゃないんだよ
Rustのエラー処理に必要な「それぞれ簡単で単純なパターン」を網羅的に知識として仕入れてRustのエラー処理はこうやってやるものだと自信を持って言えるようになるまでの学習効率の問題
anyhow/thiserrorはそのパターンを楽に使えるよう作られてるから「ああRustのエラー処理ってこうやればいいんだな」ってのが標準ライブラリ前提で学ぶより断然早く理解できる
- 310 名前：デフォルトの名無しさん mailto:sage [2023/02/01(水) 22:05:04.46 ID:JRuvbVor.net]
- >>309
dynの取り扱いと「?」オペレータによる自動変換はRustの基本事項で必須の知識
もちろん標準ライブラリの中で完結して使えるしシンプル仕組みなのですぐ使えるようになる
この基本を習得せずに外部ライブラリへ行くことを勧めるのは基本知識を欠いた人を生み出してしまう愚かな行為
- 311 名前：デフォルトの名無しさん [2023/02/01(水) 22:25:39.32 ID:JqtaL/Do.net]
- >>310
もしかしてパターンってdyn Errorと?オペレータ使った自動変換の話だけなの？
それだけじゃRustで現実的にどうエラー処理を実装すべきかThe Book読み終えたくらいの人にはわかんないと思うよ
- 312 名前：デフォルトの名無しさん mailto:sage [2023/02/01(水) 22:59:41.62 ID:JRuvbVor.net]
- >>311
エラー処理パターンは様々な方針があり
その前提知識としての共通の必須事項として今回のスレの流れで話が出て来ていたdynの取り扱いと?での自動変換の話を書いた
例えばあなたが出したanyhowはdyn Errorを扱う外部ライブラリの一種
anyhow::Errorから具体的な型を取り出すためには>>305で書いたdynの取り扱い知識が必須
この知識を知らないと細かいエラー分類が出来ずにエラー表示のみしか出来ない人になってしまう
もう一つあなたが出したthiserrorも?での自動変換を用いる外部ライブラリ(というかマクロ)の一種
>>305で示したFrom::from()による自動変換の基礎知識を欠いたままでは仕組みすら分からず魔法のように外部ライブラリを使うダメな人になってしまう
応用が効かないだけでなく利用していて何か問題にハマった時に基本知識がないと解決することもできない
- 313 名前：デフォルトの名無しさん [2023/02/02(木) 00:32:13.04 ID:y8eaHXgz.net]
- >>312
設計やプラクティスとしてのパターンのことを言ってたんだが君は言語機能のことをパターンと呼んでるみたいで噛み合ってないよね
dyn Errorや?オペレータ使ってinto経由で変換されるような基本的な機能面の知識はThe Bookにも書かれてるレベルだし多少分からなくてもリファレンス読めばいいだけの話
でもそれだけの知識でRust初心者がエラー周りの実践的な設計をできるようにはならないでしょ
- 314 名前：デフォルトの名無しさん mailto:sage [2023/02/02(木) 00:53:57.92 ID:tzaW+blt.net]
- anyhow/thiserrorは最近出てきた新興ライブラリ
当然それまでは誰も使っていなかったわけで初心者がいきなり必須なものでもない
初心者にとっては複雑で機能過多で理解しにくいのでまずは標準ライブラリから始めたほうが良いかな
- 315 名前：デフォルトの名無しさん mailto:sage [2023/02/02(木) 01:38:05.78 ID:JL6WsU2I.net]
- 対象年齢付きのおもちゃか何か？w
自分だけ勝手に縛ってろw
- 316 名前：デフォルトの名無しさん mailto:sage [2023/02/02(木) 03:39:28.87 ID:S9qGtTXE.net]
- Rustは「教官付き教習車」だよ。
cとかと違ってアホが膝を撃ち抜く自由は許さない。
それが嫌ならRust止めれば？
- 317 名前：デフォルトの名無しさん mailto:sage [2023/02/02(木) 07:11:05.90 ID:02L2EQ2o.net]
- Rustはコンパイラの防波堤の中で安全な自由があるけどそれはともかく
クセの強いanyhowをRustの基本より先に初心者に教えるのはあかんよ
たとえば、他人も使うライブラリ作成ではanyhowの使用を避ける、といった当たり前のことも
エラーに関する基本を知らないと陥ってしまう
- 318 名前：デフォルトの名無しさん mailto:sage [2023/02/02(木) 07:31:00.57 ID:c3pJ+FwE.net]
- >>316
rustの免許とりたいんですがおすすめの教習所はありますか？w
- 319 名前：デフォルトの名無しさん mailto:sage [2023/02/02(木) 07:34:23.41 ID:/W20jYzd.net]
- anyhowはもはや標準ライブラリでしょ
- 320 名前：デフォルトの名無しさん mailto:sage [2023/02/02(木) 07:55:32.16 ID:Cx26n0QZ.net]
- >>317
あれはクセというよりanyhowの致命的な欠陥だ
分かってる人は配慮して閉じた環境だけで使うけど稀に公開ライブラリにanyhow使っちゃう無知な人もいる
基礎知識はホント一番大事
- 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]
- 久々に荒らし発生かな
|
 |
