- 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/
- 201 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 07:53:28.80 ID:7I30yv0f.net]
- >>200
コードレビューやリファクタリングや移植作業をしたことがあればそれがコードに見えないことは非常に困ると分かる
Rustはそれがはっきりと分かるため可読性が良い
- 202 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 07:59:50.04 ID:Tm4r8coX.net]
- mainからリターンするのであればプログラムの終了に至る条件が増えるほどmainの条件分岐がでかくなる
ってことも理解できない人がpanicダメとか言っているんだね
- 203 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 08:27:46.22 ID:cn1TJfcU.net]
- このスレ見ていると、Rust勉強しているのにコールスタックとかスタックフレームを理解していないやつて意外と多いのが分かるな。
そもそもmainはスタックの根元で、OSとかプログラマーから見てプログラムそのものの代表だろ。
正常なフローならmainで始まってmainで終わるのは定石であって、正常なフローを破壊するpanicは異常事態。
Rustはスタックを重視してResultとか?演算子とか整備しているんだから、わざわざ用途外でpanicを使うのはRustのコンセプトを理解できていない証拠。そんなにスタックフレームのフロー制御が嫌ならRust以外を使ったら？
- 204 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 08:35:12.13 ID:7I30yv0f.net]
- >>202
そもそもpanicするのはメモリ不足くらいしかない
それも最近はtry_reserve()などpanicを避ける対応も増えてきたがまだpush_within_capacity()など安定化していないな
あと固定サイズ内でやりくりするArrayVecのtry_push()を使うこともよくある
- 205 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 08:36:17.38 ID:mKWzzzcA.net]
- 例外がないせいで、複数ライブラリ使うとエラー型を合成する必要があってつらいわ
- 206 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 08:39:39.26 ID:08CfuspX.net]
- >>200
入れ子になった関数の途中かどうかなんて関係なく、自身が呼び出した関数から出る例外に無関係な状況など考えにくいんだが
- 207 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 08:41:05.82 ID:YNMDboNb.net]
- >>201
何が困るのか具体的に書いてみ
- 208 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 08:42:54.02 ID:YNMDboNb.net]
- >>206
自分が関与しない例外なんだろ？
その関数にできることなんてないはずだが？
- 209 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 08:43:45.56 ID:7I30yv0f.net]
- >>205
それは"?"オペレータのところでFrom::from(err)変換が自動適用されるので変換をimplしておけばよいだけ
- 210 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 08:49:38.58 ID:3fV3plkN.net]
- panic派の主張は「肥大化するとなんかダサいからエラー処理サボってpanicさせとくわ。コード量は減ってスッキリするから格好いいでしょ」という風にしか聞こえない
どれだけ肥大化しようとも想定が必要なエラー処理を省略しては駄目だろう
- 211 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 08:49:41.53 ID:7I30yv0f.net]
- >>207
例外がそこを通過するのか否かそこを見ただけで分からないからレビューでもリファクタリングでも何でも不便すぎる
一方でRustはそこがはっきりしていて可読性が良い
未処理な事項があって上位へ処理を委託していると明確に分かる
- 212 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 08:51:55.45 ID:LXCt1d5H.net]
- >>205
とりあえず合成したいならanyhow使えばいい
勝手に全部合成されるから使い勝手は例外と変わらんと思うよ
- 213 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 09:03:32.22 ID:cRk5v+aU.net]
- >>212
anyhowで勝手に合成されたエラー型への参照をmain()のifで場合分けしようとしたけど
JSのinstanceof 演算子的な処理のやり方が分からんかったわ
- 214 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 09:09:12.08 ID:YNMDboNb.net]
- >>211
だから不便すぎるとかふわふわした言葉で語るなよw
具体的に何が不便なんだよ
- 215 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 09:12:07.56 ID:YNMDboNb.net]
- >>210
panicはバグとかメモリー不足とかでどうしようない状態になったときに呼び出されるもので通常のエラー処理なんてできないってことぐらい理解しなよ
- 216 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 09:18:10.08 ID:7I30yv0f.net]
- >>213
そういう使い方をしたいならば例えばライブラリA,B,Cに対してMyErrorをEnumでErrorA,ErrorB,ErrorC各収容した方が扱いやすさも効率も良い
そのEnumに格納するだけのコードimpl From<MyError> for ErrorAしておくだけで簡単
- 217 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 09:23:20.28 ID:cRk5v+aU.net]
- >>216
全部自動でやってよ
- 218 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 09:28:45.86 ID:7I30yv0f.net]
- >>214
Rustでは通過する途中の関数においても"?"オペレータの有無で未処理エラーを上位へ委託しているか否かが明白に分かる
だからコードレビューがしやすいし機能追加やリファクタリングする時にも見落としがない
一方で例外機構のある多くの言語では通過する途中の関数を見ても例外が通過するのか否かすら分からない
範囲を大きく広げて探し回らないといけなくなりムダな作業も発生して不便である
- 219 名前：デフォルトの名無しさん [2023/01/31(火) 10:14:19.93 ID:PU9Vswnw.net]
- >>205
自分のcrate用にエラーenumを定義して下位のエラーはそれにwrapするんだよ
その辺を楽させてくれるのがthiserror
カスタムな例外を定義しなくてもBulit-inの例外を使い回すだけで規模の小さいプログラムなら書ける例外+継承のある言語とは違うところ
Rustの場合はioエラーのみとかじゃなければ常にエラーenumを書くようになる
- 220 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 10:15:37.08 ID:YNMDboNb.net]
- >>218
だから自分が関与しない例外を調べて何をするんだ？
例外使うなら例外安全に作るのは当たり前でその関数が関与したリソースはその関数がきちんと始末することでなんの問題もないでしょ？
- 221 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 10:18:35.43 ID:7I30yv0f.net]
- >>217
そこは自由度があるから自分で必要性に応じて仕様を決めるべき
完全にサボりたいならanyhow等を使えばよいがその代わりにdynによる非効率さと分類の扱いにくさがトレードオフ
- 222 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 10:29:38.37 ID:7I30yv0f.net]
- >>220
中間関数は関与していないのではなくcatchしないことで例外エラーを上位へ移譲している
機能追加やリファクタリングではその処理位置が変わり得るから無関係ではなく把握する必要がある
同じことをRustならば上位への移譲があるか否かが明確に分かるため非常にやりやすい
- 223 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 10:37:25.48 ID:YNMDboNb.net]
- >>222
> 機能追加やリファクタリングではその処理位置が変わり得るから無関係ではなく把握する必要がある
そりゃその関数が関与するような修正するならな、当たり前
でも全ての関数が毎回関与するわけじゃないだろ
なんかダメな理由を必死に探してるとしか思えないけど
- 224 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 10:41:06.15 ID:7I30yv0f.net]
- >>223
コードレビューでも同じ
上位への移譲の有無がはっきり分かるRustは可読性が良い
- 225 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 11:26:55.99 ID:5zDIQfkR.net]
- メモリ不足でパニックとか言っている時点で全く判かっていないの草
メモリのアロケーションに失敗した場合パニックしてもその動作は保証されない
なぜならスタックの巻き戻し中にメモリのアロケーションが試みられないことを保証するのは難しいからだ
そのアロケーションに失敗した場合に二重パニックになる
パニック時にアボートする場合は別だが、その場合はリソースやロックの開放もれが発生する可能性があるね
- 226 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 11:52:51.31 ID:df6faTWR.net]
- >>225
全然ここの話を聞いてなかったけど、C++だとデストラクタは内部で例外を発生しては
ならないと決まっているから、デストラクタ内部ではメモリー不足例外も
発生させてはならない。
- 227 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 11:55:03.20 ID:df6faTWR.net]
- >>226
[補足]
Java などでは、例外を投げるには throw new SomeException(); のようにするが、
C++ では、throw SomeException() のようにする。つまり、前者はヒープから、
後者はスタックから例外オブジェクトを確保する。なので、例外throwそれ自体は
メモリー不足にはならない。
- 228 名前：デフォルトの名無しさん [2023/01/31(火) 11:56:57.46 ID:eIPLUE+9.net]
- Resultでエラーを表現する一番の目的は
抜け漏れなくエラー対応してることを
シグニチャーを見ただけでわかるようにして
簡単に静的チェックができるようにするため
- 229 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 12:41:27.68 ID:YNMDboNb.net]
- >>224
いらない情報書かれても読みにくいだけ
- 230 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 12:44:13.13 ID:+FKSpugG.net]
- 今日もpanic警察が必死です。MISRA-C警察みたい
- 231 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 12:45:18.07 ID:YNMDboNb.net]
- >>225
メモリー不足で動作が保証されないなんて常色だろ
同じくプログラマーの想定外の場合でも動作は保証できないからそういう時は余計なことしないで早期に終了させるしかない
panicってそのためのものだよ
なので個人的にはrustのスタック巻き戻しはやり過ぎだと思ってる
- 232 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 12:46:06.11 ID:YNMDboNb.net]
- >>230
必要ないと思うなら使わなきゃいいのになぜか鬼の敵みたいになってるの草
- 233 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 12:47:09.57 ID:oegPHy5Y.net]
- panic使う人は使っても困らないような
プログラム開発してるだけ
本人が困ってないならそっとしておけ
- 234 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 12:51:11.39 ID:CpP2rI02.net]
- panicを使う理由が対応コード書くのがめんどくさいとか見通しとか回復可能でも呼ぶぜってところからきた話なので
回復不能エラーで呼び出された場合とか当たり前なところ話しても議論にもならんやろ
- 235 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 14:46:39.65 ID:YNMDboNb.net]
- > 本人が困ってないならそっとしておけ
と言いながら構わずに居られない>>233であったw
- 236 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 15:00:44.42 ID:hwxs0+db.net]
- 病院行ったほうがいいよ
- 237 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 15:03:53.55 ID:ylr44mGO.net]
- >>233
元からそういう話だぞ。panic原理主義者が発狂しているだけで
- 238 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 15:10:39.60 ID:3fV3plkN.net]
- 簡単にpanicされると困るようなプログラム作りたいからこそrust選んだのでは
- 239 名前：デフォルトの名無しさん [2023/01/31(火) 15:39:37.08 ID:CAp90nIJ.net]
- JavaやC#あたりの経験もなくPythonやJavaScriptしか触ったことがない層がRustをやろうとしてるんだろうな
そうでもないと説明がつかない
- 240 名前：デフォルトの名無しさん [2023/01/31(火) 15:48:38.88 ID:BgaMS/KG.net]
- 言語というよりはエラー種別やドメインエラーをきちんと定義するようなアプリやシステムの開発経験がないからだと思われる
- 241 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 15:52:55.96 ID:+s4b9MNJ.net]
- おじおじしてきたな
- 242 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 16:06:06.73 ID:YNMDboNb.net]
- 単発ワラワラw
- 243 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 16:33:36.83 ID:hwxs0+db.net]
- 自分以外がすべて同一人物が書いたかのように見えるなら病院に行きなさいって
- 244 名前：デフォルトの名無しさん [2023/01/31(火) 16:45:54.71 ID:VKWM6Cjq.net]
- 複オジ2世レベルやな
立場逆転してるのが感慨深い
- 245 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 16:51:02.90 ID:+s4b9MNJ.net]
- そういえばこんなのもあったな
使ってやってくれ
Rustレスバトル会場
https://mevius.5ch.net/test/read.cgi/tech/1657382429/
- 246 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 17:01:16.78 ID:k74gCp3T.net]
- レスバしたいだけにしか見えねえ
- 247 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 17:26:31.56 ID:5mHFhJcn.net]
- GoとかRustとか例外サポートしなくなった言語、標準でスタックトレースサポートしなくなった辛さにみんなどう対応してるのかね。
エラーメッセージで grep とか、ログからコールスタックを想像とか、かなり辛いんですけど。
- 248 名前：デフォルトの名無しさん [2023/01/31(火) 17:30:47.95 ID:fFj0kljj.net]
- スタックトレースサポートされてるぞ
だかスタックトレースないとどこでエラーが発生したかわからないような作りは見直すべき
- 249 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 18:11:46.10 ID:CpP2rI02.net]
- 古き良きline!マクロ
- 250 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 18:25:09.41 ID:Qz5B8C78.net]
- c++勉強しているけどやっぱりrustっていいんだな
c++の場合どのオーバーロードが足りないかもエラーをチラ見しながら勘で判断するしかない
少なくとも能力の低いワイはそうやって対処している
- 251 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 19:05:37.94 ID:Tu8zoz2s.net]
- 例外連呼しているくせに具体的なことを書かない時点でエアプか煽りなんだろうな
例外機構を持つ処理系はエラー処理を局所化できるメリットがある
同様のメリットをRustで得るにはどのような実装が推奨されるんかな？
- 252 名前：デフォルトの名無しさん [2023/01/31(火) 19:31:24.49 ID:p+H/rvZ9.net]
- そこまで言うなら見せてもらおうか。
スレッド間エラー転送とやらを。
- 253 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 19:36:37.66 ID:94wkFUZO.net]
- https://i.imgur.com/f1bKLY1.png
- 254 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 19:41:28.43 ID:7I30yv0f.net]
- >>229
Rustの利点に対して「いらない情報」と言い張るのはまるでアンチのように悪意があるなあ
可読性の向上という開発効率でのメリットと実行効率のメリットさらにスレッドやコルーチン実装のタスクからも伝播させることができるRust方式は非常に優れているよ
- 255 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 19:47:33.31 ID:YNMDboNb.net]
- >>254
だからその情報がなぜ必要なのかを書きなよ
毎回可読性の向上って念仏唱えられても困る
- 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のコレクションを返せばいい
例外のある言語でもこのケースは例外じゃなくエラー情報を貯めたオブジェクトを戻り値で返してエラーがあったかどうかをチェックして分岐するコードを書く
それと似たようなもの
>例えば「関数内で細切れでファイルに書き込んでいるとき、どこかで書き込みエラーが出たらロールバックしてログを取って再書き込みする」とか。
ロールバックする系の処理ならエラーを貯めずにエラーが一つ出た時点で中断するように作ったほうがいい
|
 |
