Rust part33

**デフォルトの名無しさん** · 2025/11/24(月) 18:48:01.50

>>897
それはnullチェックをしていないため安全でない
unwrapは必ずnullチェックをする安全な方法

**デフォルトの名無しさん** · 2025/11/24(月) 18:53:21.46

>>898
何年前に出て、現在どれだけ使われてるの？

**デフォルトの名無しさん** · 2025/11/24(月) 19:30:54.35

>>900
JavaScriptランタイムのBun
あと、SUSEがZigでSSHの再実装するらしい

**デフォルトの名無しさん** · 2025/11/24(月) 19:58:53.90

>>901
聞いたのは個別具体な事例ではなく、どれだけ使われているか、つまり普及のいかんについてであるのと、あと出た時期Rustと変わんなくない？

**デフォルトの名無しさん** · 2025/11/24(月) 21:00:06.05

Crate.ioには、std::fmt::Debugをインプリしていないクレートが一杯あるんやね。
UartDriverだけかと思いきや、結構ある。
Wrapper作ってのインプリ作業がマンドクセ。
でないと、クレート、モジュールの外部変数Mutex.setもできん。
いろいろ手間のかかる言語だ。

**デフォルトの名無しさん** · 2025/11/24(月) 21:14:00.28

ラップして Debug を実装するだけならマクロでかなり自動化できると思う。
というかそういうクレートはありそう。知らんけど。

**デフォルトの名無しさん** · 2025/11/24(月) 22:02:41.96

>>896
言語に機能は備わっているけど誤った使い方でそれを活用できていない人たちがいるという話に対して「unwrapは必ずnullチェックをする」という言語に備わった機能を紹介しても意味ないでしょ

ちなみにnull safetyは必ずnullチェックがなされることを指すわけではないよ
null safetyを実現するための一手段ではあるけれどね

**デフォルトの名無しさん** · 2025/11/24(月) 22:03:30.71

>>903
これまで誰も困っていないのならば
あなたがおかしい可能性を疑ってみてはいかが

**デフォルトの名無しさん** · 2025/11/24(月) 22:07:33.53

>>905
その件は一方的な特定の価値観によって「誤った使い方」と断言してる人がおかしい
まずケースバイケースであり更に同じケースでも価値観の相違がある話なので技術的な話ではない

**デフォルトの名無しさん** · 2025/11/24(月) 22:25:07.64

>>907
ケースバイケースなのは当然の話なんだがunwrapの誤った使い方によって大障害につながったCloudflareのケースを念頭に話をしてるわけで

あれが「誤った使い方」と断言できない人がこんなスレだけで複数いることがRustの抱えてる問題

**デフォルトの名無しさん** · 2025/11/24(月) 22:28:17.91

>>908
本気で言ってるなら正気を疑う
まず思い込みの前提から解放されよう

**デフォルトの名無しさん** · 2025/11/24(月) 22:31:40.94

>>906
Rust API Guidelines でもパブリックな型にはDebugトレイトを実装することを推奨してるけど
https://rust-lang.github.io/api-guidelines/debuggability.html

**デフォルトの名無しさん** · 2025/11/24(月) 22:32:27.20

>>908
その無理矢理な「Rustの抱えている問題」との書き込みからアンチらしき人にみえます

**デフォルトの名無しさん** · 2025/11/24(月) 22:41:07.93

「所有権の複製」の人って
その発言の前はそもそもクソコードいっぱいこのスレに書いてた人よな？
あの人よくunwrap書いてたような記憶あるけど記憶違いかな

**デフォルトの名無しさん** · 2025/11/24(月) 23:02:06.99

unwrap使わない人はassertも使わないのかな
条件が破れた時にpanicの発生源になるし

**デフォルトの名無しさん** · 2025/11/25(火) 00:13:09.71

除算は常にchecked_div使ってそう

**デフォルトの名無しさん** · 2025/11/25(火) 00:17:03.45

物事を点でしかとらえられない知的障害者が大勢いるのがよくわかってかなしい
早くAIに置換したい

**デフォルトの名無しさん** · 2025/11/25(火) 00:21:51.64

0か100か思考の例

**デフォルトの名無しさん** · 2025/11/25(火) 01:08:59.76

>>909
Cloudflareのunwrapの使い方が誤った使い方でないと思ってるならそう思う根拠を述べて反論できないの？

**デフォルトの名無しさん** · 2025/11/25(火) 03:59:13.06

>>917
あちこちでの議論くらい読め
Resultを返す関数の中で意図的にResultをunwrapしていることから
そこでエラーは起きないと確信していて起きたら停止すべき事態とみなしている
現実にもありえない重複行が発生してサイズオーバーという異常事態になっていた
あとは運用側の問題でありpanicによりどこで何が起きたか確実に判明して直ぐに対応できる話だがここでは対象外

**デフォルトの名無しさん** · 2025/11/25(火) 07:01:05.47

>>918
そのあたりはコーダーの都合であって、運用を危険にさらす理由にならない。

Cloudflareの場合で言うなら、
https://blog.cloudflare.com/ja-jp/18-november-2025-outage/
ボット管理モジュールのフィーチャー設定ファイルは長さに上限が無いにもかかわらず固定長のメモリに保存する仕様にしているのだから、固定長を超えるフィーチャー設定ファイルが来るのは当然ありえるケースとしてカバーする必要がある。それをコーダーの都合で雑にpanicさせて、なおかつ「panicのあとは運用側の問題」と放り投げるなら>881>884という話だわな。

**デフォルトの名無しさん** · 2025/11/25(火) 07:48:13.19

運用上マズい結果を招きかねないコードがそのまんまテストやレビューを通過していることから、これは組織体制の問題でもある
どのようなテスト結果をもってどのように承認されたのか、今回の事象に至る前提条件はその時に把握されていたのか、等が気になる

**デフォルトの名無しさん** · 2025/11/25(火) 07:52:14.10

>>919
理解できない人なのかな？
そんな憶測の話はどうでもいい
きりがない
重要なことは何を意図して今回のコードを書いているかどうか

今回はResultを返す関数の中で意図的にResultをunwrapしていることから
そこでエラーは起きないと確信していて起きたら停止すべき事態とみなしている
そして異常事態が実際に起きてここで食い止めることができている

もちろんこれらの事象が起きて事後知識を得た後には別の判断をする可能性がある
その一つがボット判断の無効化など異常事態でも動かし続けることを優先するだろう
これらの事後知識を得た後の話をしても意味がない

**デフォルトの名無しさん** · 2025/11/25(火) 08:15:03.85

>>921
コーダー視点からすればそうなのね。

それならなおさらのこと、マネジメント視点や運用視点からすればpanicは厳重に管理しなければならない対象ということになり、>881という結論になるわな。
さらに言えば>920の指摘の通りで、雑に実装された緊急停止コードがレビューでそのまま本番環境に投入されたのは組織体制の問題があるかもしれん。実際にはRustのバッドノウハウの普及遅れのせいだと思うけど。

**デフォルトの名無しさん** · 2025/11/25(火) 10:56:07.08

>>921
>そこでエラーは起きないと確信していて起きたら停止すべき事態とみなしている
めっちゃ憶測やん

**デフォルトの名無しさん** · 2025/11/25(火) 11:05:24.61

複おじの憶測が当たってても誤ったunwrapの使い方であることに変わりはないよね

**デフォルトの名無しさん** · 2025/11/25(火) 11:49:12.51

クラウドフレアって良く落ちるよね

**デフォルトの名無しさん** · 2025/11/25(火) 13:01:07.06

>>921
コードは（もっと言えば仕様も）意図を100%反映するものではない
コードにunwrap()があるからといってそこから背景の意図を一意に読み取れるとする前提は、ソフトウェア工学の現実にまったく即していない

**デフォルトの名無しさん** · 2025/11/25(火) 13:11:04.76

設定ファイルはデフォルトのものは用意出来なかったのだろうか
デフォルトの設定を使ったら動作変わるだろうけどそれよりはpanicのほうがマシということかな