Rust part30

**デフォルトの名無しさん** · 2025/05/28(水) 09:31:36.60

公式
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 part29
https://mevius.5ch.net/test/read.cgi/tech/1746200850/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2025/06/10(火) 08:56:00.68

マクロが無ければコンパイルはもうずいぶん速くなってただろう
再コンパイルで全体を書き換えとかしなくても良かった
マクロは害でしかない

**デフォルトの名無しさん** · 2025/06/10(火) 11:28:46.69

>>720
英語の原文の意図の話題と捉えていただきたい
訳語そのものに意味があるのではないし

**デフォルトの名無しさん** · 2025/06/10(火) 11:59:27.98

printlnは害でしかないという結論になればそれはそれでいい
一番困るのは、printlnは友達だけどマクロは排除するべきみたいなやつ

**デフォルトの名無しさん** · 2025/06/10(火) 12:27:09.64

自分でマクロを封印しておいてRustは記述量が多いとか文句言う人も見かける
「マクロ＝悪」の先入観で最初から視野に入れてないなら仕方ないけど

**デフォルトの名無しさん** · 2025/06/10(火) 12:50:16.80

そういや、printlnがマクロなのは、どういう設計上の判断なのかな？

**デフォルトの名無しさん** · 2025/06/10(火) 12:53:12.95

>>725
Rustが可変長引数書けないクソ言語だからだろ

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

Rustの次の言語に期待してる

**デフォルトの名無しさん** · 2025/06/10(火) 14:11:45.11

>>726
その辺からガチガチなんだな

**デフォルトの名無しさん** · 2025/06/10(火) 16:00:17.82

>>726
どの静的型付け言語の可変長引数も末尾に同じ型で暗黙に個数を渡す
Rustはスライスで対応してる

**デフォルトの名無しさん** · 2025/06/10(火) 16:03:19.17

一方でprintf系はどの安全な言語も静的に個数と型チェックするため言語組み込みになっていてRustも同じ

**デフォルトの名無しさん** · 2025/06/10(火) 16:13:36.43

言語組み込みでもRustなら関数風手続きマクロと同じ形にできるのでprintなどformat系はマクロ記法

**デフォルトの名無しさん** · 2025/06/10(火) 16:47:51.11

うわでた

**デフォルトの名無しさん** · 2025/06/10(火) 16:50:41.55

RustはC++のiosteamを取り入れるべきだったね

**デフォルトの名無しさん** · 2025/06/10(火) 17:32:44.90

Rustのフォーマット文字列で変数取り込めるのは不衛生なマクロの例だよ
そもそも構文解析とは無関係に単なる文字列を独自に解釈しているから真のマクロですらない

**デフォルトの名無しさん** · 2025/06/10(火) 17:42:17.17

>>734
Rustにはprocedural macroもあるさ

**デフォルトの名無しさん** · 2025/06/10(火) 17:57:16.18

>>730
constexprと同等のコンパイル時評価ができれば言語組み込みじゃなくｋても静的に個数と型のチェックは可能だよ
亀のような歩みだけどRustも一応その方向に進んでいる

**デフォルトの名無しさん** · 2025/06/10(火) 21:25:49.21

>>734
Rustのマクロは2種類あることを理解できてない？
古典的なマクロは衛生的だよ

**デフォルトの名無しさん** · 2025/06/10(火) 21:31:17.08

>>737
そりゃ生ポを封印してスマポを使えばC++でも安全なコードが書けると言っているようなものだ

**デフォルトの名無しさん** · 2025/06/10(火) 21:53:13.37

>>738
衛生的は古典的マクロ上の概念だよ
構文木を自在に操れる手続きマクロは枠外だけど安全だよ

**デフォルトの名無しさん** · 2025/06/10(火) 22:17:06.05

今度はマクロの名称で論争すかｗ
Rustのプログラムが書かれないスレだねえｗ

**デフォルトの名無しさん** · 2025/06/10(火) 23:09:55.09

実際の所Rust使うようなのは、何かしらの他言語を相応のレベルで習得してるから
いちいち人に質問するようなことにならない

**デフォルトの名無しさん** · 2025/06/10(火) 23:33:39.35

>>704
>>707
Rustで最も使われるのは属性マクロとderiveマクロ
インライン展開のために使う人はいない

**デフォルトの名無しさん** · 2025/06/11(水) 12:22:55.52

>>677
面白そうだけど雑誌1冊に1500円か～…
普通の本買えちゃう

**はちみつ餃子** ◆8X2XSCHEME · 2025/06/11(水) 13:51:34.67

技術雑誌の値段はそんなもんだろ。
だいぶん前に休刊してしまったがオープンソースマガジンが同じくらいの値段だったはず。

**デフォルトの名無しさん** · 2025/06/11(水) 14:44:49.21

ここでしつこくRust推してるヤツといい国策か何かなの？

**デフォルトの名無しさん** · 2025/06/11(水) 14:47:38.98

脱C言語へ
米国国防総省のDARPA、CからRustへのコード変換を自動化する「TRACTOR」プログラムを開始
https://atmarkit.itmedia.co.jp/ait/spv/2408/14/news045.html

**デフォルトの名無しさん** · 2025/06/11(水) 14:51:01.80

>>745
Rust スレで何を言ってるんだ

**デフォルトの名無しさん** · 2025/06/11(水) 14:51:40.86

はちみつ餃子氏もうここには名無しとしてしか書き込まないことにしたのかと思ってたけど
切り替え面倒だしやめたんけ

**はちみつ餃子** ◆8X2XSCHEME · 2025/06/11(水) 14:57:25.35

>>748
少なくとも私が使っている専用ブラウザではコテハンの記憶はスレ単位なんだけどそうじゃないのもあるの？
スレに最初に書くときにコテハンを入れるのを忘れてそのままだったりするだけで特に意図はないよ。

**デフォルトの名無しさん** · 2025/06/11(水) 15:03:15.57

超音波と電波は頭蓋骨貫通する
傷害事件や殺人事件の被害が出ているのですが調査可能ですか

「最近もの忘れ多いかも」”超音波”が効く未来の脳ケアガジェットに期待
2025.06.11 12:00
https://ascii.jp/elem/000/004/268/4268478/
>>サウンドウェーブイノベーション株式会社が開発中の「LIPUS-Brain」という医療機器だ。頭に当てるだけで脳を優しく刺激してくれるらしい。仕組みは「低出力パルス波超音波（LIPUS）」という特殊な音を使って、脳内の血流や神経の働きをサポートするというもの。
>>　「脳に超音波って大丈夫？」と思うかもしれないが、これは低出力＆非侵襲。要は、“切らない・飲まない・痛くない”系の治療機器だ。軽症アルツハイマー病への有効性が示唆されており、2022年には厚生労働省から「先駆的医療機器」のお墨付きももらっており、現在も治験が進んでいる。
テラヘルツ波で内耳蝸牛を観察、難聴など耳の病気の診断に期待
2025年06月11日 12時00分更新
https://ascii.jp/elem/000/004/278/4278126/
>>　難聴の多くは、耳の奥にある音をつかさどる器官である内耳蝸牛（かぎゅう）の障害が原因とされています。内耳蝸牛は頭蓋骨深部にあるため、光計測では骨を透過できず、X線撮影では被ばくのリスクがあり、内部の観察が困難です。
>>可視光と電波の中間帯に位置するテラへルツ波は、内部を被ばくさせずに観察できることから、安心安全な技術として注目されています。しかし、波長は約300マイクロ（マイクロは100万分の1）メートルであり、それより小さなマイクロメートルレベルの対象物は観測できませんでした。
>>マウスを用いた実験により、テラへルツ波を利用して内耳蝸牛を観察しました。研究チームは、非線形光学結晶にフェムト（フェムトは1000兆分の1）秒オーダーの短い時間だけ強いレーザー光を照射すると、テラヘルツ波が局所的に発生して点光源として扱えることに着目。点光源から発生したテラヘルツ波が、蝸牛内部で反射して戻ってくるまでの時間を測定して距離や形状を調べる独自の手法と、機械学習を利用した画像解析法を開発しました。
>>これらを適用することで、内耳蝸牛内部の3次元構造をマイクロメートルレベルで初めて可視化し、断面観察にも成功しました。

**デフォルトの名無しさん** · 2025/06/11(水) 15:40:39.69

>>745
国が Rust を勧めるようになったら逆に大したもんだろ

**デフォルトの名無しさん** · 2025/06/11(水) 15:54:24.35

>>749
専ブラでコテ使うときの事情なんか知らんけど…
最近Rustスレにはその名前の書き込みがなかった割に、2回も書き込みあったのは別に間違えたわけでもなさそうだなって思っただけだよ
まあそういうことにしておきますか

**デフォルトの名無しさん** · 2025/06/11(水) 16:59:46.75

さっき調べて来ましたって内容を最初から知ってたかのように書く時の様々な特徴が某氏と全く同じだからバレバレなんだけどね

**デフォルトの名無しさん** · 2025/06/11(水) 17:04:07.73

さっき調べて来ましたってノリであれだけC++の話できるならそれはもう十分詳しいんよ

**はちみつ餃子** ◆8X2XSCHEME · 2025/06/11(水) 17:40:22.10

>>753
細部まで丸暗記してるわけないだろ。
根拠になる資料 (主に規格) を確認するのが当然だと私は思ってるんだが、お前は根拠のないまま書き込んでるんか？

**デフォルトの名無しさん** · 2025/06/11(水) 18:23:50.25

国策で思い出したけど
お金を使ったら10%取られて物々交換なら取られない国策あるでしょ
あれなに？

**デフォルトの名無しさん** · 2025/06/11(水) 19:02:16.12

>>756
取り締まりが不可能な規則を課しても意味がない。

**デフォルトの名無しさん** · 2025/06/11(水) 19:10:09.89

米政府「ソフトウェアはメモリ安全でなければならない」との声明を発表
「C」「C++」よりも「Rust」などの言語を推奨
https://atmarkit.itmedia.co.jp/ait/articles/2403/18/news045.html

**デフォルトの名無しさん** · 2025/06/11(水) 23:59:38.88

国策か

**デフォルトの名無しさん** · 2025/06/12(木) 00:27:35.47

linuxもmac osもwindowsも否定されたわけだ

**デフォルトの名無しさん** · 2025/06/12(木) 00:45:26.17

AppleもRustで書いてるのか
https://jobs.apple.com/en-us/details/200598995/
Our codebase is written entirely in modern Rust

**デフォルトの名無しさん** · 2025/06/12(木) 02:14:01.75

既存の置き換えは時間かかるけど
新たなものはC/C++使わずRustが各社の方針

**デフォルトの名無しさん** · 2025/06/12(木) 17:21:34.63

>>761
それは、1つのプロジェクトへのプログラマー募集であってApple製品の全てではない。
>We are building a new distributed multi-tiered data orchestration service
>to support critical Artificial Intelligence/Machine Learning systems and
>services with direct business and customer value.

**デフォルトの名無しさん** · 2025/06/12(木) 18:02:28.45

新たな開発にはRustを使うという業界全体での普遍的な出来事

**デフォルトの名無しさん** · 2025/06/12(木) 18:03:51.97

え？

**デフォルトの名無しさん** · 2025/06/12(木) 20:24:11.71

最近はみんなRust使ってるよな

**デフォルトの名無しさん** · 2025/06/12(木) 22:52:10.28

環境に合わせてセキュリティ製品を無効化するRustベースのEmbargoランサムウェアを発見
https://eset-info.canon-its.jp/malware_info/special/detail/250114.html

BlackCatとHiveに続き、EmbargoグループもRustでランサムウェアペイロードを開発しています。
プロセスのスキャンと強制終了は、RayonというRustのデータ並列化ライブラリを利用して、複数のスレッドに分割されます。

**デフォルトの名無しさん** · 2025/06/12(木) 23:47:21.12

どこもかしこもRust製だな

**デフォルトの名無しさん** · 2025/06/13(金) 00:50:30.07

犯罪者もRustかい

**デフォルトの名無しさん** · 2025/06/13(金) 07:58:36.41

rustスレだけ勢いあるな

**デフォルトの名無しさん** · 2025/06/13(金) 09:22:19.66

もうRust以外の言語に存在価値がないからな

**デフォルトの名無しさん** · 2025/06/13(金) 10:38:02.99

Cのマクロってdefineのこと？

**デフォルトの名無しさん** · 2025/06/13(金) 10:41:53.68

一人でレスパしてる香具師
めっちゃ当てはまっててワロス
watch?v=nsCKf0aQmDk

**デフォルトの名無しさん** · 2025/06/13(金) 12:11:18.07

これからの時代、プログラミングスキルを磨いて、意味あるのかな？
お仕事は、生成AIにもっていかれるのに

**デフォルトの名無しさん** · 2025/06/13(金) 13:37:48.88

>>774
化石になるほど使い物にならなくなる訳じゃないだろう
例えば停電した途端に仕事できなくなって納期守れないようなAIより俺らの方がまだ早いじゃん
想定が局所的か、、、

**デフォルトの名無しさん** · 2025/06/13(金) 14:44:41.80

AIによる内製化が進むに従ってITエンジニアもユーザー企業に直接所属するケースが増えるだろうから、そっちに行ければ定年まで安泰だろう
Rustに自己肯定感を求めてるようなタイプの人達に社内の御用聞きが務まるか、そもそもやりたいかは疑問だが

**デフォルトの名無しさん** · 2025/06/13(金) 15:28:24.55

AIの時代は当然Rust一択

**デフォルトの名無しさん** · 2025/06/13(金) 17:47:14.23

全部をAIに任せられるほど甘くないだろ
AIに細かく指示出すより自分でコード書いて見せた方が早い領域は残る

**デフォルトの名無しさん** · 2025/06/13(金) 18:16:39.57

特定の言語でプログラムが書けるみたいな狭義かつ低次のプログラミングスキルは特定メーカーのワープロでタイピングができるとか特定メーカーの表計算ソフトが使えるとかそういうのと同じコモディティ化したスキルになっていく

大事なのは特定の言語に依存しないメタなプログラミングスキルのほう

**デフォルトの名無しさん** · 2025/06/13(金) 18:27:02.35

それはそうだけど個別言語スレで言うことじゃないすぎる

**デフォルトの名無しさん** · 2025/06/13(金) 18:27:31.78

>>778
コーディング能力は既に人間の方が下だから、下等な我々が細かく指示出すより、
ブラックボックスの仕様から好きに実装していただいて説明してもらった方がよい

**デフォルトの名無しさん** · 2025/06/13(金) 19:32:43.29

コモディティ化してもしなくても偶然にすぎない
偶然の産物は観察や考察するよりも編集してカットしたほうがいい
しかし編集すればするほど雑音が増えると思ってる人達にはそれができない

**デフォルトの名無しさん** · 2025/06/13(金) 19:45:58.10

>>779
その通り
特にRustも使えないと今後はプログラマ失格

**デフォルトの名無しさん** · 2025/06/13(金) 22:56:19.01

jemallocはマジで終了だってさ
https://jasone.github.io/2025/06/12/jemalloc-postmortem/

**デフォルトの名無しさん** · 2025/06/13(金) 23:27:33.59

>>784
終わってない、とかほざいてた人はどうなん？

**デフォルトの名無しさん** · 2025/06/13(金) 23:44:49.92

>>784
2017年にFacebookを去った時点で手を引いて現Meta管轄なんだな

**デフォルトの名無しさん** · 2025/06/14(土) 00:01:13.21

>>786
その記事の内容を読んでそういう感想なら死んでるのと変わらない

**デフォルトの名無しさん** · 2025/06/14(土) 13:57:15.87

形式的には Meta が管理下に置いていたプロジェクトであるというのは間違いではないでしょ。
その上で Meta は全然やる気がなくなってるというだけで。 (少なくとも Jason の視点ではそう見えている。)

**デフォルトの名無しさん** · 2025/06/14(土) 14:50:51.36

凄腕のエンジニア達が長い時間をかけて育ててきたjemallocといえども、
アリーナアロケーションのようなアプリケーション依存の原始的な手法には敵わないってのは虚しい話だな
特にRust信者はともすると小手先の技巧にかまけて視野が狭くなりがちだから気をつけなければならない

**デフォルトの名無しさん** · 2025/06/14(土) 15:08:08.30

jemallocがMETAの管理下に入ってMETA寄りの機能を実装する開発方針に切り替わった
そして一般よりの機能を削減して一般からそっぽを向かれた
作者自身も一般からの需要にが付いていなかった

結局jemallocはMETA向けに局所最適化されてそこから一般向けに戻すにはかなりの人員と労力が必要だけど
それに見合うだけのメンテナーも資金もどこからも出てこない
実質死んでますよと

こういう内容

**デフォルトの名無しさん** · 2025/06/14(土) 15:13:02.44

資金力があるところに吸収されて開発されてもそれが必ずしも良いことではないと言うことだ
吸収する側には目的があって吸収して機能を実装し終わったらそれでもう満足なんだ

**デフォルトの名無しさん** · 2025/06/14(土) 15:48:51.99

万能なメモリアロケータは実現不可能
どういう用途に効率を特化するかで無数に分かれる

**デフォルトの名無しさん** · 2025/06/14(土) 15:53:14.56

>>789
最適なタイミングでまとめて確保と解放するアリーナ方式が最も性能出るのは自明

**デフォルトの名無しさん** · 2025/06/14(土) 19:21:21.54

mRNAワクチンの“新たな懸念”接種済み妊婦の子どもに「異常タンパク質構造」血中で確認★2 [Gecko★]
2025/06/14(土) 15:48:24.59
https://asahi.5ch.net/test/read.cgi/newsplus/1749883704/

・ワクチン問題になっている

**デフォルトの名無しさん** · 2025/06/14(土) 20:11:15.75

jemallocがRustから外されて各OSの標準アロケーターに戻った理由も重要だよね

**デフォルトの名無しさん** · 2025/06/14(土) 22:46:25.65

性能は用途により一長一短
特定のアロケータが標準だとバイナリサイズで不利なため

**デフォルトの名無しさん** · 2025/06/15(日) 00:30:17.16

#[global_allocator]標準化が1.28でjemalloc非標準化が1.32だな
外した理由はブログで書いてる
https://blog.rust-lang.org/2018/08/02/Rust-1.28/#global-allocators
https://blog.rust-lang.org/2019/01/17/Rust-1.32.0/#jemalloc-is-removed-by-default

**デフォルトの名無しさん** · 2025/06/15(日) 00:56:18.63

システム開発言語であるのにシステムのメモリアロケーターを使っていない

**デフォルトの名無しさん** · 2025/06/15(日) 00:59:44.98

Rustにおけるシステムプログラミングというのは「ケチ臭いプログラミング」と読み替えるとよい
必ずしも低レベルであることを意味しない

**デフォルトの名無しさん** · 2025/06/15(日) 09:10:25.99

jemalloc使用するとメモリが300kb消費されると
rustプログラム一個につき300kb

**デフォルトの名無しさん** · 2025/06/15(日) 21:04:59.71

組み込み開発はRust一択

**デフォルトの名無しさん** · 2025/06/15(日) 21:27:38.86

WEB開発もERust一択

**デフォルトの名無しさん** · 2025/06/15(日) 21:37:03.14

今日もRustで組み込み開発しちゃった

**デフォルトの名無しさん** · 2025/06/15(日) 22:40:54.62

俺はC++で開発し続けているが。

**デフォルトの名無しさん** · 2025/06/15(日) 23:08:21.56

組込みデバイスのRustのサポート状況ってどうなん？
少し前にNVIDIAのJetsonを触ったことがあるんだけと、SDKやサンプルはC++が基本だったと思う
(例えばJetson multimedia APIというのがあって、デバイス付属のGPUで動画をエンコードする等ができるんだけど、これはC++のクラスを使うAPIだから他の言語からFFIしづらい)

こういうのがRustに対応するようになるまでは、この分野はまだしばらくC++中心になるんじゃないかと思う
ラズパイなんかはRustの話も聞くし、できることは増えてると思うけど

**デフォルトの名無しさん** · 2025/06/16(月) 02:15:29.18

メジャーなCPUならそれなりに対応してると思う
https://doc.rust-lang.org/beta/rustc/platform-support.html

SDKは需要とベンダーのやる気次第

**デフォルトの名無しさん** · 2025/06/16(月) 05:39:40.78

ヌルポ😳😳

Google Cloud、世界中のリージョンが影響を受けた大規模障害、原因は管理システムがヌルポインタ参照でクラッシュしたこと
2025年6月16日
https://www.publickey1.jp/blog/25/google_cloud_3.html

**デフォルトの名無しさん** · 2025/06/16(月) 06:07:30.55

記事あんま理解できてないけどヌルポインタってそんなにまずいもんなの？
コンパイラーが検出してくれるし、スコープから外れた変数はドロップされるからそもそも参照されないかと思ってた

**デフォルトの名無しさん** · 2025/06/16(月) 06:43:29.69

ヌルポインタ参照って
プログラムをCとかunsafeとか使わずにRustで全て作ってるとしたら起き得ないことであってる？

**デフォルトの名無しさん** · 2025/06/16(月) 08:20:04.56

>>808-809
ヌルポインタの問題は型の非互換性、本質的には機能の非互換性の問題。

古いJavaで顕著だけど、ヌルポインタは何の機能もサポートしないのにコンパイル時はほとんどすべての型に化けることができるから、コンパイル時に問題を発見できずに実行時に問題になることがある。
本来なら互換性を保つためにヌルオブジェクトとかを使うべきだけど、言語で禁止しているわけではないので、低能力コーダーとか無能ライブラリアンとかはヌルポインタを返す関数とかを作って問題になる。

safe rust は基本的にヌルポインタを使えないので、このようなトラブルになることは少ないかと。

**デフォルトの名無しさん** · 2025/06/16(月) 11:48:14.62

問題の本質はヌルポじゃないだろ
publickeyの人はそれがわかってない

てかGoogleの品質管理体制も杜撰すぎるな

**デフォルトの名無しさん** · 2025/06/16(月) 12:21:10.35

ガッ！

**デフォルトの名無しさん** · 2025/06/16(月) 12:30:45.07

空白のフィールド含んだだけでクラッシュとかよく分かんないよ
俺がテストせずにこのプログラムをリリースさせた責任者だったら会社に残れないな。明らかにテスト捏造してるから
——
新しいポリシーデータには意図せず空白のフィールドが含まれており、これをサービスコントロールが読み込んで実行したところ、ヌルポインタ参照となりクラッシュが発生します
——

**デフォルトの名無しさん** · 2025/06/16(月) 13:38:36.81

要は不具合を引き起こす特定のパターンがあり、テストで発見されなかったってことだろ
たまたま結果としてヌルポでクラッシュしただけで、仮にヌルポの可能性に気づけていたとしてもそれ自体がバグの原因でない以上、
問題のパターンが別の形で障害を起こしていた可能性を否定できないな

**デフォルトの名無しさん** · 2025/06/16(月) 14:56:07.05

もしRustで実装していれば、パニックですんでいたのにな

**デフォルトの名無しさん** · 2025/06/16(月) 15:28:10.23

今回の事態を招いた最も重大な要因は「リリース手続きの欠陥」であって、ヌルポ参照という"クラッシュに至る個別の事象"に着目した対策に終始するのは悪手（ヌルポ参照以外の要因で本件のような事象が再発しても良いのか、という問いにyesと答えることに他ならない）

**デフォルトの名無しさん** · 2025/06/16(月) 15:38:50.32

>>814
>要は不具合を引き起こす特定のパターンがあり、テストで発見されなかったってことだろ

特定のパターンというか「新機能のために新しく適用する全世界共通のポリシーデータ」と「新機能」の組み合わせでクラッシュするんだから本番環境に適用するポリシーデータでは一切テストしてなかったってことでしょ

feature flagがなければステージングでのテストも行わず本番と同時適用ってのも意味がわからない

**デフォルトの名無しさん** · 2025/06/16(月) 15:40:30.06

>>815
パニックでも結果は同じ

**デフォルトの名無しさん** · 2025/06/16(月) 16:50:55.12

>>815
Rustで実装していればOption型になる
unwrapしない限りpanicは起きない

**デフォルトの名無しさん** · 2025/06/16(月) 17:11:52.79

JavaはTとOption<T>を区別しないからStringでもnull検査パスしてるか分からんのよね
誰かが検査してると思ってたら誰も検査してなかったり逆に至る所で何重にも検査されてたり