- 1 名前：デフォルトの名無しさん [2024/02/23(金) 17:37:52.13 ID:CheDQupm.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 part22
https://mevius.5ch.net/test/read.cgi/tech/1705760500/
ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.2ch.net/test/read.cgi/tech/1514107621/
- 357 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 01:39:19.40 ID:t5wrhqh7.net]
- >>350
俺んとこもそのコードはよく書くけれど
今回の敗因は引数のindexが生のusizeであること
そこをusize直接ではなくそのラッピングの専用型にする
そしてその専用型が動く範囲が必ず範囲内であることを保証する形で
get_uncheckefのunsafeを使う関数をsafeに仕上げる
- 358 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 19:05:54.93 ID:QWnK+qvS.net]
- unsafeを適切に使えないプログラマが書くと全然安全じゃないという事？
- 359 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 19:57:12.18 ID:7RDAu5V5.net]
- 全然そういう事
Rustで無闇にunsafeを使うのは日本語で無闇に「全然」を使うくらいやばい
- 360 名前：デフォルトの名無しさん [2024/03/21(木) 20:09:58.67 ID:gM/gTjZ5.net]
- >>353
それ言うなら
無闇に「ヤバい」を使うぐらいヤバい
じゃね
- 361 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 20:26:53.11 ID:1l7zk65j.net]
- 俺はむやみに「全然」とか「ヤバい」を使ってるけどトラブルになったことはないな
ガンガンunsafe使ってこーぜ！！
- 362 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 20:28:39.30 ID:7RDAu5V5.net]
- >>354
それだと単なる自己言及だから352に対する答えとして不十分では
- 363 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 20:45:04.06 ID:t5wrhqh7.net]
- 少なくとも>>350のindex: usizeは
何らかラッピング { index: usize }と別型にすべきところ
まず範囲外のusizeでうっかり使っても型エラーにできる
そしてラッピング型の動作が必ず範囲内に収まるコードであることを注視するだけで安全性を保証できる
- 364 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 21:05:14.02 ID:7RDAu5V5.net]
- NonZeroとかNonNullみたいな固定条件ならいいけど
範囲みたいな可変条件だと型だけじゃ厳しいでしょ
別の条件で作られた同じ型の値を使われるかもしれないし
ライフタイム
- 365 名前：で条件と関連付けるのも限界がある
結局テストパターン増やしてdebug_assert踏むしかない [] - [ここ壊れてます]
- 366 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 21:44:37.76 ID:t5wrhqh7.net]
- >>358
もちろん二段階
まずは専用型にすることで管轄外のusize indexがうっかり混じるのを型エラーで確実に避ける
次にコーディングやレビューやメンテでその専用型の動きに注視できる
- 367 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 22:18:44.86 ID:cOunjWn7.net]
- unsafeをsafeでないのにsafeにしておいて
ある型が使い方によってはunsafeになるかもしれないから注視しろってのはちょっとキツイです
- 368 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 22:27:42.27 ID:WuGieKPN.net]
- 結局プログラマが色々意識してコーディングしないと安全にはならないのね
こういうのもコンパイラがエラーにしてくれてそれを直していけば安全になるものだと思ってたんですけど
- 369 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 23:07:15.31 ID:7RDAu5V5.net]
- unsafeに手を出さなければ最悪でも暴走する前にpanicで停止する安全性は確保できる
実際は安全の為でもpanicで止まると困るから色々注意しないといけないし
unsafeで余計なチェック省いたり黒魔術使ったりもする
Rustの安全性のサポートは選択と集中がしやすくなる程度で万能ではない
- 370 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 23:12:07.53 ID:v/mpoJJ8.net]
- >>361
unsafeを使わなれば自動的に安全が保証される
unsafeを使うならその関連箇所に人間による安全保証が必要、それ以外は自動的に安全が保証される
C/C++はすべてのコードがunsafe状態なので自動的に安全が保証されるところがない
- 371 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 23:22:25.34 ID:WuGieKPN.net]
- いつもの人がきたｗ
結局レベルの低い人が書くとunsafeも不適切に使われて今回のように脆弱性が出てしまうでしょ
Rustであれば安全と思ってる人が多そうなのでかえってunsafeによる脆弱性が見落とされたり発覚しにくくなって問題だと思うんですけど
- 372 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 23:58:23.31 ID:z414Bs3I.net]
- > Rustであれば安全と思ってる人が多そう
いや一応言っとくけど多くはないよ流石にｗ
一部の人が連呼してるだけ
ほかの人はもっと現実的だろな
- 373 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 23:59:21.08 ID:t5wrhqh7.net]
- 原則はunsafeを使うな！
これだけだ
理解できていてunsafeを使う場合も
とにかく閉じ込めろ！
専用のクレートを作れ
専用のモジュールを作れ
専用の型を作れ
- 374 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 23:59:51.15 ID:XJ9dJAV6.net]
- unsafe使わなければ安全
- 375 名前：デフォルトの名無しさん [2024/03/22(金) 09:16:28.77 ID:IQ7X1X+j.net]
- まあ実際rustはコンパイル通ればいいの思想を強める傾向にはある。
それは意識して気をつけた方がいい。
- 376 名前：デフォルトの名無しさん mailto:sage [2024/03/22(金) 10:19:34.77 ID:avPqaarP.net]
- ロジックや言語仕様を考えずにコンパイルが通るまでひたすらいじくり回すタイプの人間は本当にいる。
チュートリアルすら読まずに書き始めてなんもわからんから教えてと質問サイトに投稿しちゃうやつはいる。
そういうやつは早めに脱落して欲しいし大抵は脱落していくんだけどどういうわけか生き残ってあらゆるところをワヤにしていく狂人がたまにいるんだよ……
普通に現実を見ながらちゃんと学べる人なら (たまにはミスることもあるだろうけど) 大丈夫だよ。
- 377 名前：デフォルトの名無しさん [2024/03/22(金) 11:58:26.79 ID:7Rs7masV.net]
- >>358
0〜127の範囲のみを取りうるようなEnumなら作れる
wasmiの例のように実行時にバッファサイズが変動するなら無意味だけど
サイズが変動する場合はget_uncheckedに必要な安全性の保証をsafe wrapperの中でやるのが基本
それができないならunsafeのままにして上位で安全性を保証させるようにしないといけない
>>359のやり方はそれができてないように感じる
- 378 名前：デフォルトの名無しさん mailto:sage [2024/03/22(金) 12:34:01.41 ID:TbCMvv+/.net]
- 実行時に範囲が変動するといっても制御下にあるのだからindexがその範囲にある時のみ有効な型を実装すればよい
そうすればその型に対して常に安全にget_uncheckedを使える
- 379 名前：デフォルトの名無しさん mailto:sage [2024/03/22(金) 14:04:42.65 ID:ZrfX32kv.net]
- Rustは失敗言語
- 380 名前：デフォルトの名無しさん mailto:sage [2024/03/22(金) 14:10:55.04 ID:ceR9yHkM.net]
- 今回の件でRustの安全性が確実になったのが興味深いよな
アンチが必死に探してきた問題も>>350でunsafe利用だった
- 381 名前：デフォルトの名無しさん mailto:sage [2024/03/22(金) 16:00:31.63 ID:JqYXTM4B.net]
- >>371
「indexがその範囲にある時のみ有効な型」の意味がよく分かってないけど
実行時に型の方でindex検査して無効時にpanic起こすなら普通にusizeでgetしてunwrapしようよ
unsafeにする意味がない
- 382 名前：デフォルトの名無しさん mailto:sage [2024/03/22(金) 17:14:19.13 ID:vuLWDWdh.net]
- >>374
実行時コストをかけないためにget_uncheckedを使うのが一般的
その代わりロジックでindexが範囲内であることを保証する(ことがてきる時に使われる汎用的な手法)
- 383 名前：デフォルトの名無しさん [2024/03/22(金) 19:27:28.32 ID:G6tKD1fj.net]
- Adaなら特定の範囲の型作れるみたいよ
- 384 名前：デフォルトの名無しさん mailto:sage [2024/03/22(金) 20:07:18.97 ID:vuLWDWdh.net]
- 今回は範囲が固定ではなく変わり得る
- 385 名前：デフォルトの名無しさん mailto:sage [2024/03/23(土) 23:29:45.64 ID:eeq00BcS.net]
- 誰にでもunsafeが使えてしまうのが問題なのでは？
原則使えないくらいが、バカでも安全になるからRustの方向性に合ってる気がする。
- 386 名前：デフォルトの名無しさん mailto:sage [2024/03/24(日) 00:34:36.37 ID:iaJ2USO3.net]
- Rust の制限は機械的に検証可能な範囲に絞ったらそうなったということであって、その制限の範囲内で十分にプログラムが書けるというものでもない。
まあ思ったよりも足りるけどやっぱり必要だから unsafe はある。
- 387 名前：デフォルトの名無しさん [2024/03/24(日) 10:55:06.56 ID:UXqlkypu.net]
- >>375
「indexがその範囲にある時のみ有効な型」でも有効範囲が実行時に変動するなら>>350の引数のindexをその型に変えたところでsafeにしたらダメだよ
- 388 名前：デフォルトの名無しさん mailto:sage [2024/03/24(日) 11:08:34.82 ID:BHU0SFkf.net]
- なるほど、欲しい機能を実装していったら、結構安全になったって感じなのかな。OpenBSDみたいな偏執なのとは違う感じか？
- 389 名前：デフォルトの名無しさん [2024/03/24(日) 11:48:11.45 ID:uu8/yG2s.net]
- indexの境界チェックが律速になるようなコード書いてみてえな
- 390 名前：デフォルトの名無しさん mailto:sage [2024/03/24(日) 20:37:14.59 ID:YsO86RjG.net]
- >>376 型宣言の時に type My_Int is range -1 .. 5; 範囲宣言(マイナスでも、１からでもＯＫ)できて、範囲を越えたらエラー 配列もその範囲指定で自由に作成できる。
- 391 名前：デフォルトの名無しさん [2024/03/24(日) 20:45:58.90 ID:Rrl8qRWO.net]
- >>383
定数じゃなければ結局実行時にチェックするってことだよね
- 392 名前：デフォルトの名無しさん [2024/03/25(月) 01:12:47.74 ID:yMlw6u5B.net]
- >>384
新しい型はint型とは独立した型なんだから変数にしたってその新しい型じゃないとコンパイル時にエラー。
- 393 名前：デフォルトの名無しさん mailto:sage [2024/03/25(月) 07:21:41.59 ID:CNajD+3j.net]
- >>384 何十年も前なのですまそ
array(-2)とかarray(6)をアクセスしたら例外発生 array(-1)はOK
type Month is range 1..12
type Month_Array is array(Month) of Integer;
ma : Month_Array := (1,2,3,4,5,6,7,8,9,10,11,12);
for m in ma'first..ma'last loop // カウンタは1から12
ma(m) = m;
end loop;
- 394 名前：デフォルトの名無しさん mailto:sage [2024/03/25(月) 14:37:28.19 ID:x/lXcXel.net]
- 今回の話は実行時境界チェックを無くす(減らす)実行時コスト削減の話だけど
そのAdaの例だと実行時に範囲外に値が動けてアクセスで例外発生するから何の解決にもなっていないね
- 395 名前：デフォルトの名無しさん mailto:sage [2024/03/25(月) 16:23:44.40 ID:9GDk/VLW.net]
- How much does Rust's bounds checking actually cost?
https://blog.readyset.io/bounds-checks/
- 396 名前：デフォルトの名無しさん [2024/03/25(月) 17:27:16.04 ID:MT/jL+52.net]
- こんなもんjavaの速度低下が境界値チェックによるものじゃないってことで話は終わっとると思ったけどな。
問題は浮動小数の取り扱いだっての。
- 397 名前：デフォルトの名無しさん mailto:sage [2024/03/25(月) 21:23:48.62 ID:x/lXcXel.net]
- unsafeは可能な限り避けるべきで
safe Rustでの改善をまずすべき
その次にindex checkの有無で意味のあるパフォ向上がある時のみ考える
現実にはsafe Rustでの改善ができてないことが多い
例えばよく見かける例としては
iが動いていくのにa[i]でアクセスしてしまう
これはiの範囲checkとa[i]の範囲checkで二重checkになるbad pattern
参照(ポインタ)化することで範囲checkを1回に減らせる
- 398 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 15:06:55.14 ID:g9hYSxJr.net]
- unsafeは極力避けろというアドバイスばっかりでunsafeを適切に閉じ込める基本的な考え方や実装パターンの啓蒙が不十分なんだよね
unsafeを良く知れば知るほど自然と避けるようになるから避けろ避けろと言うよりもunsafeに関する知識を深められるようにする方が大事
- 399 名前：デフォルトの名無しさん [2024/03/27(水) 15:29:03.70 ID:pFQTMi8v.net]
- 「unsafeの閉じ込めにはセンスがいるから、教えてもらわないと出来ないやつはunsafeを使うな」
が言える限界な気がする。現にunsafeを適切に閉じ込めるためのノウハウを継承できる資料とかがないので
- 400 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 16:02:47.08 ID:BwG0n/Az.net]
- unsafeはライブラリ作者とかがハード周りアクセスするために使うもので、コーダーが使うものじゃないだろ。
unsafe可能ソースファイル用の拡張子を別途用意して、rsファイルはunsafe禁止にしてもいいくらいじゃない？
- 401 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 16:59:36.71 ID:LwoOYerE.net]
- >>393
そしたら全部を unsafe 可能版で書いちゃうのが世の中の現実ってもんなんだよ。
- 402 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 17:05:39.09 ID:6Vj8sISV.net]
- >>392
センスの問題ではないと思うが仮にセンスが必要だとしてもセンスがあるやつが適切に閉じ込めた事例とダメな事例を類型化してパターンナレッジとして浸透させればいいだけ
今はそれが全然できてないから>>350のような基本的なミスを犯すやつが後を絶たない
- 403 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 17:08:09.55 ID:6japDZ8y.net]
- windows-rs とか使うと絶望するよな。もうちょいラップして安全なAPIも提供してほしい。
- 404 名前：デフォルトの名無しさん [2024/03/27(水) 18:09:17.85 ID:345wycOn.net]
- >>395
～すればいいだけって言う奴はたいてい本人はやらないんだよなぁ。
- 405 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 18:27:03.05 ID:3NgGdhlw.net]
- >>397
問題点の指摘や解決策の提案と
問題解決のために実際に誰が動くのかという
2つの異なるものを混同したらだめだよ
マネジメント101
- 406 名前：デフォルトの名無しさん [2024/03/27(水) 18:54:43.86 ID:nHNmKGrp.net]
- その素晴らしい提案がなぜされていないのか考えよう
そしてなぜ自分は実行から逃げているのか考えよう
- 407 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 20:42:45.86 ID:deTzlgug.net]
- >>394
Rustが流行りそうな一番の理由は「管理側」が「コーダー」にunsafeみたいなことをやらせたくないということなんだから、どこでもunsafeとか管理側が許さんだろ。
- 408 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 21:06:58.89 ID:LwoOYerE.net]
- unsafe はコンパイラが安全性を「論理的に検証できない」部分であって、理論上の都合で出来た区分だよ。
危険な操作も含まれるけど危険な部分を分けれてるわけではない。
もちろん unsafe を制限する規約のプロジェクトがあったって良いが、そのための機能じゃないよ。
- 409 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 21
]
- [ここ壊れてます]
- 410 名前：:18:47.87 ID:deTzlgug.net mailto: >>401
安全性をコンパイラが検証できないなら、なおのこと制限すべきだと思うがね。
デフォルト禁止でもいいくらい。 [] - [ここ壊れてます]
- 411 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 21:31:01.25 ID:LwoOYerE.net]
- >>402
だからそうしたいならそうすりゃいいって話をしてる。
あなたが裁量権をもつプロジェクトでは。
私が反論してるのは「そのためのものだ」という部分に対して。
- 412 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 21:44:58.62 ID:deTzlgug.net]
- >>403
Rustのコンセプトとニーズからすれば、どこでもunsafe使えるのは中途半端だ、ということだよ。
unsafeはデフォルト禁止でいいよ。
- 413 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 21:49:49.48 ID:Fy0R0co2.net]
- 理想をいえばunsafeなんて無いならサイコーだったんだろうね
rust陣営もしゃあなしでunsafe導入したんやろうし
unsafeなしですべてがセーフで効率的だったら
そりゃあrustは本当に素晴らしい文句なしの言語だったやろな
- 414 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 22:08:33.46 ID:toZsv7uT.net]
- 生ポインタすなわちCPUによるメモリアクセスはunsafe
そこが出発点
unsafeを組み合わせてunsafeを閉じ込めたsafeなインタフェースを提供できる
それがsafe Rustの基本原理
つまりunsafeに行き着くためunsafe無しでは何もできない
これが真理
一方で
unsafeを閉じ込めたライブラリ利用可を前提にすれば
unsafeを用いないsafe Rustでほとんど大抵のことが実現できるのも事実
- 415 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 22:24:02.18 ID:cgbLYCC5.net]
- >>406
だったらデフォルトunsafe禁止で良い。
どこでもunsafe okはやっぱりチグハグ。
- 416 名前：デフォルトの名無しさん [2024/03/27(水) 22:52:47.09 ID:qNf/D02g.net]
- そこまでsafeな事にこだわるなら、Haskellに行けばいいのでは…？
- 417 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 22:57:38.14 ID:LwoOYerE.net]
- >>404
「そうであって欲しいと自分は思っている」なら別にいいよ。
ニーズとかコンセプトとか、ありもしないものを根拠にしてることに反論されてるんだよ。
- 418 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 23:02:28.02 ID:toZsv7uT.net]
- #![forbid(unsafe_code)]
を宣言すればいい
もちろんすべてはunsafeへ行き着くため
unsafeを禁止できるのは自分のコード部分だけ
- 419 名前：デフォルトの名無しさん [2024/03/27(水) 23:55:45.93 ID:pFQTMi8v.net]
- unsafeな部分の拡張子を変えるというのが有効とはあんま思えんのだよな
平気でunsafe使ってくるガイジは当然平気でunsafeな拡張子を使ってくるだろうという予想する
- 420 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 07:44:09.91 ID:OabXy/xk.net]
- >>409
公式の「効率的で信頼できるソフトウェアを誰もがつくれる言語」に従うなら、安全でもなくて誰もが使えるわけでもないunsafeはデフォルト禁止にすべきだろ。やっぱりチグハグだわ。
>>411
拡張子以外だとどんなのができるかねぇ。コーダー向けRustとライブラリアン向けRustで完全に分けるぐらい？
- 421 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 08:15:17.48 ID:wHq/ItvK.net]
- rustもいろいろ問題を抱えてるんだね
プログラマの習熟が必要だっていうなら流行らないだろう
メモリ安全なソフトウェア書くことを優先するなら土方が適当に使えるjavaやc#があるだろうし
新しいc/c++/rustと競合する決定版のような言語が出てきてrustはさらなる傍流に押しやられそう
- 422 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 08:34:31.08 ID:5loDhjzb.net]
- >>412
こう書くだけでunsafeの使用が禁止されます
#![forbid(unsafe_code)]
>>413
普通の人はunsafeなんか使いませんからRustは安全で何も問題ありません
- 423 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 08:48:28.49 ID:OabXy/xk.net]
- >>414
>411みたいなマキャベリガイジが混ざると破綻しますな。
MSとかGoogleとかの管理側がRustに期待するのはそういった部分含めた安全性だろ。
- 424 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 09:00:19.29 ID:5loDhjzb.net]
- >>415
これでunsafeが使用禁止となり安全なsafe Rustになる
#![forbid(unsafe_code)]
コンパイラがunsafeをエラーとして弾く
- 425 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 10:37:24.50 ID:dWo+4s1T.net]
- 結局いつもの「無知なアンチ vs 無知な信者」の薄っぺらい対立になっちゃうのな
- 426 名前：デフォルトの名無しさん [2024/03/28(木) 14:03:58.90 ID:61/ABBlz.net]
- まあハスケルなんかもinvalidな変数使うようにっての広めるのには役立ったからrustもそういう位置に落ち着くだろ。
- 427 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 17:41:01.08 ID:Li+1uESY.net]
- unsafeを使う人はライブラリ作成者がほとんどで、残りはシビアなインフラ作成者
一般プログラマーはunsafeを使わずに、unsafeが閉じ止められたライブラリのsafeなインターフェースのみ用いる
もしunsafeを用いて閉じ込めてsafeなインターフェースを提供できる新たなパターンを発見した時のみ、
その部分だけを切り出してライブラリ作成者になれる
それができない一般プログラマーはunsafeに縁がなく、unsafeを気にする必要がない
- 428 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 18:27:15.03 ID:OabXy/xk.net]
- >>419
そうならやっぱりデフォルト禁止にすべきだな。一般コーダーはunsafeを使えないようにしてコードの安全性を高めるべき。
Rustのデフォルトムーブとかshared xor mutableとかは安全側に倒しているのに、なんでunsafeだけはユルユルなのかね。
- 429 名前：デフォルトの名無しさん [2024/03/28(木) 18:35:39.73 ID:2Ez7VURh.net]
- unsafeって書かないといけないってのは結構デフォ禁止よりの処置だと思うが
このメッセージが伝わらない相手にはもうunsafeの文法を分けてunsafeだけ難しくするとかしかなさそう
でもわざわざ難しい文法を用意すると言うのも馬鹿らしい話だ
- 430 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 18:56:54.80 ID:Hx0Q8eMq.net]
- 必要な各企業、各プロジェクトなどで義務付け
#![forbid(unsafe_code)]
これでunsafeの話はおしまい
他の言語と比べてRustはコーディング規約もAPI規約も公式で楽
Rust公式APIガイドライン
https://rust-lang.github.io/api-guidelines/
- 431 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 19:45:10.84 ID:OabXy/xk.net]
- >>422
公式のドキュメントで
#![forbid(unsafe_code)]
の説明を探しているんだけど、どこにあるのかしらん？
doc.rust-lang.org/nomicon/safe-unsafe-meaning.html
の１行でおしまい？
- 432 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 20:08:10.91 ID:uNPCtnZO.net]
- forbidもunsafe_codeもrustcのlintの一部だな
doc.rust-lang.org/rustc/lints/levels.html#forbid
doc.rust-lang.org/rustc/lints/listing/allowed-by-default.html#unsafe-code
- 433 名前：デフォルトの名無しさん [2024/03/28(木) 21:59:19.02 ID:vhhc95Ef.net]
- Rust Foundationによる資格認定試験に合格した者だけにunsafe使用パスワードが発行されるようにするしかないな。
- 434 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 22:34:58.42 ID:jTiWvkZ+.net]
- どの開発でも
#![forbid(unsafe_code)]が原則
どうしてもunsafeが必要なら
その安全ロジックを関係者で協議後に
#![deny(unsafe_code)]へそのモジュールのみ変更し
許可する部分のみを
#![allow(unsafe_code)]として監視対象
といった感じが一般的かと
監視対象を極一部に限定できて
全体はコンパイラにより保証できるため
他のプログラミング言語より扱いやすい
- 435 名前：デフォルトの名無しさん [2024/03/28(木) 22:41:56.41 ID:8+kd1npI.net]
- >>420
一般とそうでない奴は誰がどうやって区別するのさ？
- 436 名前：デフォルトの名無しさん [2024/03/28(木) 22:42:31.88 ID:8+kd1npI.net]
- >>421
正解
- 437 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 23:58:52.21 ID:KGiLR8kg.net]
- 時間がない時はunsafe使っていいよ
- 438 名前：デフォルトの名無しさん [2024/03/29(金) 00:05:51.94 ID:B//2x2dm.net]
- 時間がない時に焦ってunsafe使って書いたコードは長期利用すると大変なことになるので書いてから1時間以内に使って捨てよう
- 439 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 00:19:58.75 ID:Rgc3qInF.net]
- >>429
safeで書くのが早くて楽で安全
わずかでもパフォ上げる必要性のあるような箇所が生じない限り、unsafeを検討する人は存在しない
- 440 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 00:24:32.79 ID:Rgc3qInF.net]
- >>430
unsafeの使用は、その論拠の安全性の検討や、それ以前に必要性の検討などが必要となるため、時間がかかる
safe Rustが楽で早く書けて安全
- 441 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 01:57:50.63 ID:EplliVDI.net]
- 壊れたレコードオジ怖い
- 442 名前：デフォルトの名無しさん [2024/03/29(金) 02:36:16.29 ID:B//2x2dm.net]
- >>432
安全性の検討も必要な検討も全部スキップして「えいや」ってやればsafe rustより速く書き上がることもあるのでは？
- 443 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 07:36:27.65 ID:9Pm5HVgJ.net]
- 雑にunsafe使って早く書けるのはFFIくらいかな
FFIはどのみちunsafe必須だけど、事前条件とかの検討せずに雑にsafe化してしまうならそれは確かに早い
pure Rustでunsafeの方が早いケースはちょっと思いつかないな
- 444 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 08:25:13.35 ID:bd1Zch8f.net]
- >>427
そりゃプロジェクト管理者だろ。
そもそもRust採用するメリットはソースコードの品質管理しか無いし。
デフォルトunsafe禁止は何回か話題に出てきているのな。
- 445 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 08:27:22.40 ID:bd1Zch8f.net]
- >>426
それぐらいやらないとRust採用するメリット無さそうだよな。
- 446 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 08:41:03.04 ID:ev5kqnbp.net]
- 初心者ぼく「禁止しないといけないようなもんが標準で使えるって結局それ危険な言語なんでは？
- 447 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 09:16:34.82 ID:cTkAvXQI.net]
- そもそも普通に書いててunsafe使いたいなって場面がない
多人数で書いてるならforbidで落としてもいいけど
コードレビューでちょっとでも見ればunsafe使ってることは明らかなんだし、いずれにしてもどうでもいい
- 448 名前：デフォルトの名無しさん [2024/03/29(金) 09:24:57.68 ID:vaG7EqUh.net]
- >>436
じゃunsafe使うな、で済む話じゃん。
- 449 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 09:49:54.05 ID:AosFf04R.net]
- >>440
そうだね
で？
- 450 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 11:01:08.74 ID:8PtB/vi4.net]
- rustもプログラマがザコだと使いこなせない言語なんだろ？
人材確保すら苦労するってメジャーになれるのかよ
- 451 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 11:23:44.57 ID:34VMnlB4.net]
- unsafeでサッと書いたほうが出世できるぞ
- 452 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 11:49:42.05 ID:ZM8BmiyA.net]
- たしかにプログラムの品質がいいから出世するって見たことないわ
逆にクソ過ぎて出世できない奴はいるかも知れんがそういう奴はプログラム云々の問題ではないからな
- 453 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 11:53:12.39 ID:opHbD1qf.net]
- unsafeは面倒
Rustで書いていてunsafeを使いたい気分になることがない
さらに通常のプログラミングでunsafeを使うメリットがあるケースが訪れることはまずない
- 454 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 11:54:18.08 ID:K6ErCtbZ.net]
- >>442
メジャーになれなくて何か問題あるの？
- 455 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 12:08:03.79 ID:6hM9S6Vd.net]
- 初心者や一般的な人は、unsafeの使い所がないなら、unsafeを使うようなすごい人でもミスをしたり理解不足だったりするって事だから、すごい人が精進すれば解決でしょ。
- 456 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 12:08:08.24 ID:GuqFwMZD.net]
- >>440
PMやったこと無いの？
unsafe使うなと管理するより、そもそも使えない方が遥かに楽。
- 457 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 12:13:58.45 ID:E/kaNL72.net]
- >>442
C++ とかだと使いこなせてないのになんとなく動いちゃったりするから……
使えてないなら使えないほうがちょっとマシなんだよ。
|
 |
