Rust part29

**デフォルトの名無しさん** · 2025/05/03(土) 00:47:30.13

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

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

**デフォルトの名無しさん** · 2025/05/09(金) 11:50:43.35

Rustがこのままオワコンになったら撤廃もあり得るだろ

**デフォルトの名無しさん** · 2025/05/09(金) 11:56:12.65

AWSもRust製か
Rust製のクラウドとJava製のクラウドが競争したらJava側が100%負けるだろうしな

**デフォルトの名無しさん** · 2025/05/09(金) 12:53:15.09

クラウドってなに？
ハイパーバイザがrustで作り直されたの？

**デフォルトの名無しさん** · 2025/05/09(金) 14:06:44.17

>>286
これは誤訳
原文だと、それらのサービスにRustを使っていると書かれているだけ
RedditなんかでAWS社員のコメントとか探してみりゃわかるが、AWSは基本Java

**デフォルトの名無しさん** · 2025/05/09(金) 15:01:02.33

エネルギー効率に劣るJavaなんかで構築していたら笑うわ
>>286でもそう書いてるよな

**デフォルトの名無しさん** · 2025/05/09(金) 15:25:02.70

Rustって人気なのね
AIにC#から移植できる？って聞いてみたらいやだって言われちゃったからRustが広まるの、なんか困る

**デフォルトの名無しさん** · 2025/05/09(金) 15:30:45.33

JVM前提な特殊環境を除き
Rustの登場でJavaを使う意味は全くなくなった

**デフォルトの名無しさん** · 2025/05/09(金) 15:41:48.51

何の前提も縛りも無い環境こそが特殊

**デフォルトの名無しさん** · 2025/05/09(金) 15:59:06.67

コンテナ化は Java の有力なメリットだったけど Docker の隆盛で様変わりしちゃったね。

**デフォルトの名無しさん** · 2025/05/09(金) 18:53:55.90

>>293
いやだと言うAI、なんかいいな

**デフォルトの名無しさん** · 2025/05/09(金) 22:11:52.71

>>291
サービス提供には安全性が一番重要なのでC++ではなくJavaを採用していた
Javaより安全で性能の良いRustが出現したため切り替えた
そしてAWSが発起人となってRust Foundationを設立した

**デフォルトの名無しさん** · 2025/05/10(土) 00:48:13.31

Rustで戦う領域ではない気もするけど、エンタープライズ向けはまだ弱いと思う
ここはまだJavaや.NETの資産が大きい

「ファイルが見つかりません」みたいにユーザーの言語でエラーメッセージが出たり、文字列のソート (例えば「あアいイ」のように、ひらがなカタカナを考慮した自然な順になる) だったり、そういうのが外部ライブラリ無しで揃ってるのが Java や .NET なわけで

規模としては相対的に小さくなってるけど、こういうのが必要な領域は普通にあるし、Javaが消えることは無いと思う

**デフォルトの名無しさん** · 2025/05/10(土) 01:05:07.51

>>299
外部ライブラリ無しで揃ってるという発想が頭おかしい
そんな間違った奇妙な視点を持ってしまうとRustには正規表現も乱数も何もかも存在しないことになるぞ
考えを改めなさい

**デフォルトの名無しさん** · 2025/05/10(土) 01:42:38.39

ここでグチャグチャ言ってる間に徐々に置き換わって行きそうだな

**デフォルトの名無しさん** · 2025/05/10(土) 03:04:27.68

firefoxが全部Rustに置き換わるのに100年ぐらい掛かりそうだけどな

**デフォルトの名無しさん** · 2025/05/10(土) 03:26:38.07

止まってるFirefoxより
ChromeとIEが着々とRust化を進めてるから先だろな

**デフォルトの名無しさん** · 2025/05/10(土) 08:39:56.30

IE?

**デフォルトの名無しさん** · 2025/05/10(土) 08:45:29.97

>>300
何でこいつ偉そうなんだ？

**デフォルトの名無しさん** · 2025/05/10(土) 08:47:09.62

>>299
人月業界は考えるだけ無駄として、SaaSだと新規開発は圧倒的にフルスタックTypeScriptが多いね
Rustは海外では革新的なDB作るぜみたいなエンタープライズの基盤系スタートアップでの採用例は見かけるが、国内ではその手のスタートアップは皆無に近いから絶望的な状況

**デフォルトの名無しさん** · 2025/05/10(土) 09:09:05.25

品質に関する考え方は良い要素を揃えれば良くなるという単純なものじゃないよ。
結局のところ、どんな問題が出てくるかは事前にわからない。
出てきた問題に対処し続けるという歴史によって品質が作られるんだ。
確かに C や C++ に比べて Rust は全面的に良いけれども、活発な巨大プロジェクトではもう問題に対処しつくしていて Rust に置き換えるメリットは相対的に小さい。
部分的に Rust に置き換えることはあっても問題が起こってない箇所まで含めて全面書き換えを目指すのは割に合わない。

**デフォルトの名無しさん** · 2025/05/10(土) 09:11:51.42

>>306
サーバーサイドでTypeScriptを使っているようでは負けるわ

**デフォルトの名無しさん** · 2025/05/10(土) 09:22:18.39

>>308
「負ける」というのは何において？
Rustで実装すると、そのサービスは使いやすくなったり、機能豊富になったり、プロトタイプを高速に作ったり、ユーザーの要望をより速く実現できたりするの？

勝ち負けが決まるのって、サービスの内容、ユーザー体験、リリース速度などが重要で、それを実現できるなら言語自体はさほど重要でない
TypeScriptはエコシステムが充実してるから、それに乗っかるのは一つの選択
(バックエンドTSはつらい点もあるから、他の技術を持ってるところなら他のものの方が良いと個人的には思うけど、そういう選択肢が世の中にあって割と普通に受け入れられてるのは現実として理解してる)

**デフォルトの名無しさん** · 2025/05/10(土) 09:29:02.26

>>307
未だにC/C++が原因のセキュリティ脆弱性報告が常に何件も出続けている現実を見なきゃ

**デフォルトの名無しさん** · 2025/05/10(土) 09:43:16.06

>>309
それらの点ではどの言語でもほとんど同じだね
遅くてメモリも喰うJS/TSをフロントエンド以外で使うのは適材適所ではないから不利だけど

**デフォルトの名無しさん** · 2025/05/10(土) 09:49:57.08

仮に外部ライブラリを使ってもRustはエンプラには向かないでしょ
この分野はオラクルやMicrosoftのような企業が時間かけて作ったきたからできたもので、現状Rustはこの分野向けのライブラリが充実してるわけでもないし、Rustコミュニティが力を入れるとも思えない (したとしても優先度は低い)

それに、安定性や将来の入手性が最も必要な分野で、多くの部分をOSSに頼るというのは業界として受け入れないと思う
(昨今OSS絡みの事件は多い)

低レイヤやWebバックエンドなど、Rustが強みになる分野があるのはその通り

**デフォルトの名無しさん** · 2025/05/10(土) 09:51:04.61

>>310
それでも何十年もc++が捨てられずに使われているのはなぜかと考えたことはないのか？

**デフォルトの名無しさん** · 2025/05/10(土) 09:52:37.21

ひらがなカタカナ交じりの自然なソートなんて
今更Rustで描いても半日もかからんやろ

**デフォルトの名無しさん** · 2025/05/10(土) 09:57:05.62

c++はrustに勝てる点が全くなく既存資産だけが頼みの綱で終わりでしょう
巨大な既存資産だけは消えるまでに時間がかかることでしょう

**デフォルトの名無しさん** · 2025/05/10(土) 10:00:12.38

超超超熟練度が必要なCOBOLになる

C、C++、COBOL　まとめてC*

**デフォルトの名無しさん** · 2025/05/10(土) 10:05:17.70

>>314
漢字も当然含むし、ロシア語や中国語などを含む世界の多数の言語にも対応する必要もあるぞ？
時刻や日時の表記も国によって違う
Javaや.NETはランタイムが大きいと言われるけど、その中にはこういうのも含まれる
手間も大きいし、この分野を再実装するのも面倒でしょ
(自分が知らないだけで、既にそういう取り組みがあるのかもしれないけど)

**デフォルトの名無しさん** · 2025/05/10(土) 10:08:42.67

.NETでソートサーバを作ってそれにソートさせて結果をrustで使う

**デフォルトの名無しさん** · 2025/05/10(土) 10:09:24.80

日本だとエンプラよりは自動車の方が早いかもね
ボルボにはもう入ってるし10年以内にトヨタ車に入るくらいならあり得るかも

**デフォルトの名無しさん** · 2025/05/10(土) 10:17:39.16

システム周りでは標準で使われて、それ以外は他の言語の下請けになるのかと思ったが実際は違うと言うことか？

システム周りにもかかわらず外部に依存が必要であれば使われない
ライブラリが充実しないと完全な下請けにはなれず、c++のDLLのように一部高速化部位での限定利用になる

**デフォルトの名無しさん** · 2025/05/10(土) 10:26:23.15

証券取引みたいに、最高のパフォーマンスと最高の信頼性が求められるガチな領域もエンタープライズにあるのは事実で、
内部的にRustを使っているところがあってもおかしくはないが、そういうのって性質上外に情報が出てこないから盛り上がんないんだよね
自動運転もそうだけど、限界の性能を出そうとすると結局は頭の良い人間を上に据えたスペースシャトル型の厳格なウォーターフォールになるんで、夢がなくてつまらないという面も

**デフォルトの名無しさん** · 2025/05/10(土) 10:38:30.67

COBOL なんか古代の遺物みたいに言われつつもかなり広くつかわれてるもんな……

**デフォルトの名無しさん** · 2025/05/10(土) 10:44:10.80

最高のパフォーマンスを出すにはC/C++/Rustしかない
安全性を満たすRustは唯一の存在
これから少なくとも数十年間は天下を取るのだろう

**デフォルトの名無しさん** · 2025/05/10(土) 10:52:25.23

>>303
EDGEか

**デフォルトの名無しさん** · 2025/05/10(土) 10:55:11.42

AI が台頭してから電力使用量が劇的に伸びてるからな。
自動車の運転を人間のプロ水準で自動化するなら動力と同じくらいの電力が計算に必要という見積りもある。
AI がまだまだ伸びる分野なら効率は重要だ。
これはコストがどうのとかいうレベルではなくコストをかけても無いものは無い (足りない) という深刻な話で、プラットフォームを担う業者がいっせいに Rust に注目しているのも無理からぬことなのかもしれぬ。

**デフォルトの名無しさん** · 2025/05/10(土) 11:33:01.79

そんな見積もり知らんけど50wでLv5運転できる人間が最高だな

**デフォルトの名無しさん** · 2025/05/10(土) 13:30:52.43

やったことないけど組み込みの世界ではどうなの
Rust使われてる？

**デフォルトの名無しさん** · 2025/05/10(土) 13:34:10.15

トヨタはこの前、Rustで求人広告出してたじゃん

**デフォルトの名無しさん** · 2025/05/10(土) 13:36:27.29

組み込みはRustが多いですね
新規案件は殆どがRust
単品ではmrubyが多いですね

**デフォルトの名無しさん** · 2025/05/10(土) 14:07:29.73

トヨタ系は基本的に愛知勤務だからな
Rustでもなんでも使って求人票を飾らないと厳しいんだろう

**デフォルトの名無しさん** · 2025/05/10(土) 14:11:56.01

Rust使えるなら都落ちして田舎で開発するのも悪くないかも
今はたいていタイプスクリプトばっかだから変化が欲しい

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

TSはフロント側とサーバー側を包括するフレームワークがあるのが強いんだよね
APIを定義してフロント側とバック側を区切る開発なら、バック側はコンパイルされるものが良いというのは同意なんだけど
TSを使うメリットがないと主張してる人は、こういう技術を知らないか、机上論を述べたいだけで実際の開発はしないから生産性など関係ないという人でしょ

**デフォルトの名無しさん** · 2025/05/10(土) 15:01:33.78

>>332
その程度なら誰でも知ってるよ
SSR/SSGからhydrationしてCSRするコードも自作したことある

**デフォルトの名無しさん** · 2025/05/10(土) 15:17:51.64

今のWeb開発では、独立したバックエンドAPIはオプションだからね
Next.jsでサーバーサイドロジックが存在するのがデフォなので、よほどCPU intensiveな処理でない限りは、
Rustで別途独立したバックエンドを作ることはかえって遅延とコストを増大させる
フロントエンドまでRustエンジニアが自分で面倒見るってんなら好きにすりゃいいけど、
Rustエンジニアがフロントエンドやりたいかねえ

**デフォルトの名無しさん** · 2025/05/10(土) 15:25:32.84

フロントとバックエンドで常に齟齬が無ければいいんだけどと言う話になるとTSが出てくる

**デフォルトの名無しさん** · 2025/05/10(土) 15:32:42.03

>>334
それはJS/TSだけでやろうとするからそういう制限になってしまう
RustとWasmも組み合わせてどこまでやるかで色んなパターンがある

**デフォルトの名無しさん** · 2025/05/10(土) 15:45:18.30

>>332
RPC は昔からある取り組みじゃないか。
半世紀もかけて TS でしか実用にならない状況だと本気で思ってるのか？

**デフォルトの名無しさん** · 2025/05/10(土) 15:49:00.61

Wasmはサイズがね…
ごく最近のニュースだと、Prismaが実装をRustからTypeScriptに置き換えたのが話題になってたな
デプロイ時のサイズが問題になる分野だから妥当ではあるけど

フロントだとビルド時間の長さが課題になりそう
UIの位置やサイズを微調整したい場合でも、確認のために毎回重ためのビルドが必要になると面倒じゃない？

**デフォルトの名無しさん** · 2025/05/10(土) 15:54:13.08

>>338
UI 記述言語で書いて形になってから Wasm (にコンパイル可能なプログラミング言語) に変換するような仕組みもある。

**デフォルトの名無しさん** · 2025/05/10(土) 15:57:42.52

>>337
RPCじゃなくてUIの描画込みの話だぞ
同じフレームワーク内でクライアントサイドのレンダリングとサーバーサイドのレンダリングを繋げたりできる
>>333 が書いてるようなもの

**デフォルトの名無しさん** · 2025/05/10(土) 16:03:27.89

>>339
色んなパターンのうちそのUI記述言語を採用してのSSG/CSRのレンダリングコード共通化が有力の一つだよね
サーバーサイドからJavaScriptを完全排除してパフォーマンスを上げる方向性が正しいので

**デフォルトの名無しさん** · 2025/05/10(土) 17:37:33.64

web開発の現場に言ってRustとwasmの組合せを使いなさいと言っても鼻で笑われるだけ

**デフォルトの名無しさん** · 2025/05/10(土) 17:57:46.62

精神障害児で周りを振り回す無能です。
この業界で俺は死ぬかも。
悲しみ

**デフォルトの名無しさん** · 2025/05/10(土) 17:58:59.59

自慢したりとか怒ると自分の首を絞める。
死ぬ。
俺はプログラミング向いてないが、この業界に行くぞ。
どうも死んだほうが良い人間です。

**デフォルトの名無しさん** · 2025/05/10(土) 18:01:36.75

rustも分からんし三年間学んでプログラム書けない無能です。
質問ある？

**デフォルトの名無しさん** · 2025/05/10(土) 18:01:51.09

もちろんrustも分からん。

**デフォルトの名無しさん** · 2025/05/10(土) 18:03:05.22

rust is must

**デフォルトの名無しさん** · 2025/05/10(土) 18:03:13.86

そもそもこの世の中教えてくれない人が悪いと奥底で思っている無能。
人との縁を切って一人で後悔しがち。
ゴミ人間だよ！

**デフォルトの名無しさん** · 2025/05/10(土) 18:04:21.67

俺はガイジだ…
ガイガイガイジのガガイのガイ。
ガイジのボッチのやる気のある無能。
ゴミカス死んだほうが良い。

**デフォルトの名無しさん** · 2025/05/10(土) 18:05:59.49

がががーがががががががががががが～が～が～障害児

**デフォルトの名無しさん** · 2025/05/10(土) 18:06:29.45

我はガイジガガガイジ天地入れざる障害児

**デフォルトの名無しさん** · 2025/05/10(土) 18:11:29.44

不勉強で天地入れざると言う言葉を知らなかったが
明治とかの言葉なのかな？

学があるね

**デフォルトの名無しさん** · 2025/05/10(土) 18:22:28.75

>>352
ありがとう！
言葉を表面上の意味しか捉えられないガイジだけど、他人に迷惑かけるのは良くないよね…
スレ荒らしてすみませんでした…

**デフォルトの名無しさん** · 2025/05/10(土) 18:23:33.01

どうせ俺以外誰も見ていないから好きなだけ荒らせばいいと思うよ

**デフォルトの名無しさん** · 2025/05/10(土) 18:23:55.63

おちつきました。すみませんでした…

**デフォルトの名無しさん** · 2025/05/10(土) 18:29:52.94

>>352
抜刀隊の歌詞にあるから知ってた。
ミリタリー趣味の人ならまあまあ知ってるんじゃないかな。
私は音楽側の趣味で知ったんだけど。

**デフォルトの名無しさん** · 2025/05/10(土) 18:58:55.45

夏休みはまだ早いぞ

**デフォルトの名無しさん** · 2025/05/10(土) 19:15:47.47

業界には何らかの形でメンタルを病んでる人間が50万人以上いると思う

**デフォルトの名無しさん** · 2025/05/10(土) 19:53:17.55

このスレは特殊だから騙されないように

**デフォルトの名無しさん** · 2025/05/10(土) 20:19:31.95

自分は悪質でなければ荒らしを許容するスレにいた

そこでは荒らしとも楽しく話してそのうち荒らしが真面目なコテになったりしていた
みんなもうどこかに行ってしまったのが残念だけどそれも運命だなと

**デフォルトの名無しさん** · 2025/05/10(土) 20:45:49.44

病院行けよ
俺は今日行ったぞ

**デフォルトの名無しさん** · 2025/05/10(土) 21:12:29.85

unsafeなライブラリのラッパーでsafeに設計するのってどうやるの

**デフォルトの名無しさん** · 2025/05/10(土) 21:22:13.51

F-22 ada
F-35 C++

**デフォルトの名無しさん** · 2025/05/10(土) 21:48:52.45

>>362
結局のところ、外側から見て safe な振る舞いになるようにするというだけ。
場合によっては不可能なこともあるけど具体的な状況がわからないとなんとも言えない。

**デフォルトの名無しさん** · 2025/05/10(土) 21:52:02.98

>>362
未定義動作の可能性を排除するために必要な条件を全部チェックする
panicとデッドロックはOKらしい（停止すれば許される）

No matter what, Safe Rust can't cause Undefined Behavior.
https://doc.rust-lang.org/nomicon/safe-unsafe-meaning.html

**デフォルトの名無しさん** · 2025/05/10(土) 22:22:13.21

>>342
そういう低レベルな現場は無視してもいいんだよ
現在もJSのフレームワークは乱立しながら変化進化し続けているように多様性がある
今回の件と関係なくwasmを既に併用しているところも多いからその点もだいじょうぶ

**デフォルトの名無しさん** · 2025/05/10(土) 22:48:31.18

誰がその多様性とかについていくのか？
お前が低レベルな現場と呼ぶ環境だろう？

**デフォルトの名無しさん** · 2025/05/10(土) 23:29:16.41

フロントにRustを使ってる「高レベル」なプロダクトって何があるの？
バックエンドなら分かるけど
その基準なら世の中のビジネス的に成功してるサービスの殆どが低レベルでしょ

**デフォルトの名無しさん** · 2025/05/11(日) 00:02:17.99

>>364-365
関数の内側にunsafe書くだけ？
それだと見た目はsafeだけど内部はunsafeだから実質的にunsafeではないか？

**デフォルトの名無しさん** · 2025/05/11(日) 00:43:43.27

子供が使うバリアの高度版

**デフォルトの名無しさん** · 2025/05/11(日) 00:48:37.35

内部で使う関数がunsafeである理由を理解して未定義動作の可能性を排除できてないなら
外側の関数にもunsafeをつける約束

**デフォルトの名無しさん** · 2025/05/11(日) 00:49:47.08

unsafeは「危険」というよりも「コンパイラが安全性をチェックできない」ブロックだと思う
内部的に unsafe を使ってても、ラップした型や関数を外から使う分には安全とみなせるなら問題ない

理想的には
・内部的にunsafeを使っているけど、外から見れば安全 -> unsafe を外して良い
・内部的に unsafe を使っており、かつその関数は利用者が適切にコードを書かないと危険 -> その関数も unsafe とマークするべき

標準ライブラリやきちんとしたライブラリは基本的にこの法則に従ってる
問題はユーザーのコードで、書こうと思えば「問題はあるけど unsafe とマークされてない関数」は作れてしまう
そこは自己責任の問題

けど、セグフォみたいなバグが実際に起きた場合に、直接の原因となるコードは unsafe ブロックの中に絞れる (ことが多い) から、それでもかなりマシだと思う
C++だとコード全体が unsafe ブロックの中にあるようなものなので…

**デフォルトの名無しさん** · 2025/05/11(日) 00:50:52.82

>>365
Undefinedの有無もなにも標準化されてないからなぁ

**デフォルトの名無しさん** · 2025/05/11(日) 00:52:29.93

バリア！バリアしたから大丈夫！

**デフォルトの名無しさん** · 2025/05/11(日) 01:02:20.84

未完成らしいけど目安
https://doc.rust-lang.org/reference/behavior-considered-undefined.html

**デフォルトの名無しさん** · 2025/05/11(日) 01:18:27.03

unsafe ＝ Rustコンパイラが安全性を保証してくれない＝プログラマが自分の責任で安全性を保証しなければならない＝ C/C++と同じ状態

逆に言えば、safeつまりunsafeではない、とは、Rustコンパイラが安全性を保証できる状況にしないといけない
未定義動作がないことが根幹にある
だから未定義動作とは何か、どういう時に起きるのか、どうすれば無くせるのか、が最重要
それを完全に理解するまでは、関数内部でunsafeを使って外をsafeな関数、にする判断をしてはいけない

**デフォルトの名無しさん** · 2025/05/11(日) 01:20:41.47

unsafe functionは使いどころが微妙だね
unsafe指定の理由が不明だし基準も開発者次第でまちまち
C#みたいにunsafeにはコンテキストとしての役割しか持たせない方が一貫性がある
呼び出し元に注意させたいんならunsafe_hogeみたいなネーミングルールで十分だった

**デフォルトの名無しさん** · 2025/05/11(日) 01:31:46.55

バリアより感染症対策で流行ったゾーニングのイメージだな
感染リスクのあるunsafeゾーンと安全なsafeゾーンがあって
unsafeからsafeに持ち込むときは消毒（検査）が必須みたいな感じ

運用が雑になって事故るのも同じ

**デフォルトの名無しさん** · 2025/05/11(日) 01:36:40.21

>>376
> それを完全に理解するまでは、関数内部でunsafeを使って外をsafeな関数、にする判断をしてはいけない
それをやると、一つの関数を unsafe にした時点でそれが呼び出し元に波及して、プログラム全体に unsafe が広がらない？
深刻なバグがコード内のどこで起こってるかを特定したい場面だと、 unsafeは本当に unsafe な操作をしてる箇所に限定されてた方が探しやすいと思う

**デフォルトの名無しさん** · 2025/05/11(日) 01:47:17.60

>>377
呼び出し元に注意を持たせるものではない
unsafeブロック(関数)内はRustコンパイラが安全性を保証しない
それ以外の部分はRustコンパイラが安全性を保証してくれる
C/C++はプログラム全体がunsafeブロック内にある状況と同じと説明できる

>>379
そうだよ
理解するまではunsafeを使ったらunsafeな関数しか作れない
safeな関数にしてよいかどうかの判断が一番大事なところ
勝手に判断してsafeにしたらプログラム全体に問題が波及しかねない
まずは理解してからunsafeに手を出しましょうということ

**デフォルトの名無しさん** · 2025/05/11(日) 02:07:37.23

「unsafe利用箇所をunsafeブロックで囲えば終わり」は、よくある勘違い
まず一次的には「それを含む関数もunsafe fnにしなければならない」が正解
その上で「内部でunsafeを使ったことで生じる問題が、その関数単独でまたはモジュール全体で閉じ込めることができているかを判断できてから、ようやくunsafe fnをfnにできる」が正解

**デフォルトの名無しさん** · 2025/05/11(日) 06:19:57.03

unsafeな理由をブロック外部で処理すりゃsafeに出来るじゃん
たとえばなraw pointer参照が危険だとして渡す前にスタックまたはヒープ内の正しいアドレスであることを確認して引数を渡すとかの、外部でのチェック(unsafeに至る条件の排除)すれば無毒化できるわけで

そんなんC言語だって変わらんやん。Cで汎用的な関数書いたらほぼほぼポインターだらけになるし、ポインターのチェックせずに使うなんてことは危険すぎてありえんのと一緒やん

C言語にrustコンパイラーのunsafeの枠組みだけ組み込んでsafeじゃなきゃエラーにしますにしたら、コードの5割ぐらいはunsafeになってそうやけどな。標準ライブラリーからしていくらでも危険なアクセスできるし

**デフォルトの名無しさん** · 2025/05/11(日) 07:03:44.41

>>382
Rustでプログラミングしたことない人には理解できないのは仕方ないが的外れ
そのCで手動でチェックをして使うようなことは
Rustではunsafeを使わずとも普通に書くことができて自動的にチェックしてくれて安全かつ楽

むしろRustでunsafeを使う頻出パターンの一つは真逆
その自動チェックを無くすためにunsafeが使われる
例えばあるアルゴリズムで既に自動チェックされて既に安全なものがアルゴリズムの都合で二重に自動チェックされてしまいコンパイルでの最適化でも消えないとする
その2回目の自動チェックを無くすためにunsafeを使う
もしそのアルゴリズムが1つの関数で完了するならばその関数外に影響はないため
関数内部でunsafeを使っていても関数自体は外向けにsafeにすることができる
そのアルゴリズムで2回目の自動チェック省略が常に正しく安全なことはプログラマが安全性を保証することになる
これがunsafeを用いて極限まで速くしつつ安全な関数を生み出すRustの典型的なパターン

**デフォルトの名無しさん** · 2025/05/11(日) 08:49:42.45

https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html
これが全て
unsafe function に関しては、長文複おじが主張するほどunsafeを含む関数に対して積極的に指定すべきものではなく、
むしろ極力safeとしてラップすることを推奨するトーンで書かれているように感じる
「unsafe functionは呼び出し元に注意させるためのマーク」という解釈は適切であり、常識的に考えて中でunsafe使ってようと呼び方によって未定義動作が生じるような関数はそもそも作るべきではない

**デフォルトの名無しさん** · 2025/05/11(日) 09:06:54.66

unsafe指定の理由が不明って斬新な視点だと思うけどね
他の言語でunsafe使ってるから意味は理解出来る

**デフォルトの名無しさん** · 2025/05/11(日) 09:11:42.89

>>384
逆だぞ
未定義動作が発生しうるパーツがunsafe関数
そのパーツを上手く使ったり組み合わせたりして未定義動作を発生させなくしたものがsafe関数

**デフォルトの名無しさん** · 2025/05/11(日) 09:15:33.06

変わった人が集まって3行で済んでいた話を広げていく

**デフォルトの名無しさん** · 2025/05/11(日) 10:06:07.52

>>368
無いから自演してまでしてRustを盛り上げようしてる