Rust part23

**デフォルトの名無しさん** · 2024/02/23(金) 17:37:52.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 part22
https://mevius.5ch.net/test/read.cgi/tech/1705760500/

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

**デフォルトの名無しさん** · 2024/03/20(水) 13:48:07.28

ガベージコレクションのあるスクリプト言語であるPythonですら脆弱性でCVE出まくってるよ

**デフォルトの名無しさん** · 2024/03/20(水) 14:22:40.25

これは「メモリ安全」の外の話？中の話？

**デフォルトの名無しさん** · 2024/03/20(水) 16:11:18.74

unsafe使用箇所だからメモリ安全の外だろうな
インタプリタのスタックフレーム参照で毎回境界チェックする実装も微妙だししゃーない

**デフォルトの名無しさん** · 2024/03/20(水) 16:33:56.60

jsonの方も？

**デフォルトの名無しさん** · 2024/03/20(水) 17:50:49.65

コード見てみたが言語関係なくダメな書き方の見本ってだけだな
ttps://github.com/wasmi-labs/wasmi/commit/f7b3200e9f3dc9e2cbca966cb255c228453c792f
ttps://github.com/wasmi-labs/wasmi/blob/v0.31.0/crates/wasmi/src/engine/stack/values/mod.rs#L158-L163

修正コードは毎回境界チェックしてるのと同じ
extendする前に必ずreserve呼ばなければいけないとか反省の色が見られない

**デフォルトの名無しさん** · 2024/03/20(水) 18:13:46.74

extendという名前も実体と違ってバクの素

**デフォルトの名無しさん** · 2024/03/20(水) 18:19:15.64

修正コードはhotfixでしょ
masterブランチの方は結構手が入ってると思う

**デフォルトの名無しさん** · 2024/03/20(水) 18:27:22.61

その知識やスキルを活かして出世して欲しい

**デフォルトの名無しさん** · 2024/03/20(水) 20:04:41.25

ダメな書き方でもコンパイルが通れば安全なはずなのではｗ

**デフォルトの名無しさん** · 2024/03/20(水) 20:32:22.01

んなこたない
ダメなunsafeの使い方すれば安全じゃなくてもコンパイルは通せる

**デフォルトの名無しさん** · 2024/03/21(木) 01:05:26.83

直接の原因はunsafeなメソッドをsafeメソッドにしたこと
unsafeのsafe wrapperの質は大事
今のコードもunsafeの使い方が怪しくて信頼できない

fn get_release_unchecked_mut(&mut self, index: usize) -> &mut UntypedValue {
debug_assert!(index < self.capacity());
// Safety: This is safe since all wasmi bytecode has been validated
// during translation and therefore cannot result in out of
// bounds accesses.
unsafe { self.entries.get_unchecked_mut(index) }
}

**デフォルトの名無しさん** · 2024/03/21(木) 01:39:19.40

>>350
俺んとこもそのコードはよく書くけれど
今回の敗因は引数のindexが生のusizeであること
そこをusize直接ではなくそのラッピングの専用型にする
そしてその専用型が動く範囲が必ず範囲内であることを保証する形で
get_uncheckefのunsafeを使う関数をsafeに仕上げる

**デフォルトの名無しさん** · 2024/03/21(木) 19:05:54.93

unsafeを適切に使えないプログラマが書くと全然安全じゃないという事？

**デフォルトの名無しさん** · 2024/03/21(木) 19:57:12.18

全然そういう事

Rustで無闇にunsafeを使うのは日本語で無闇に「全然」を使うくらいやばい

**デフォルトの名無しさん** · 2024/03/21(木) 20:09:58.67

>>353
それ言うなら

無闇に「ヤバい」を使うぐらいヤバい

じゃね

**デフォルトの名無しさん** · 2024/03/21(木) 20:26:53.11

俺はむやみに「全然」とか「ヤバい」を使ってるけどトラブルになったことはないな
ガンガンunsafe使ってこーぜ！！

**デフォルトの名無しさん** · 2024/03/21(木) 20:28:39.30

>>354
それだと単なる自己言及だから352に対する答えとして不十分では

**デフォルトの名無しさん** · 2024/03/21(木) 20:45:04.06

少なくとも>>350のindex: usizeは
何らかラッピング { index: usize }と別型にすべきところ
まず範囲外のusizeでうっかり使っても型エラーにできる
そしてラッピング型の動作が必ず範囲内に収まるコードであることを注視するだけで安全性を保証できる

**デフォルトの名無しさん** · 2024/03/21(木) 21:05:14.02

NonZeroとかNonNullみたいな固定条件ならいいけど
範囲みたいな可変条件だと型だけじゃ厳しいでしょ
別の条件で作られた同じ型の値を使われるかもしれないし
ライフタイムで条件と関連付けるのも限界がある

結局テストパターン増やしてdebug_assert踏むしかない

**デフォルトの名無しさん** · 2024/03/21(木) 21:44:37.76

>>358
もちろん二段階
まずは専用型にすることで管轄外のusize indexがうっかり混じるのを型エラーで確実に避ける
次にコーディングやレビューやメンテでその専用型の動きに注視できる

**デフォルトの名無しさん** · 2024/03/21(木) 22:18:44.86

unsafeをsafeでないのにsafeにしておいて
ある型が使い方によってはunsafeになるかもしれないから注視しろってのはちょっとキツイです

**デフォルトの名無しさん** · 2024/03/21(木) 22:27:42.27

結局プログラマが色々意識してコーディングしないと安全にはならないのね
こういうのもコンパイラがエラーにしてくれてそれを直していけば安全になるものだと思ってたんですけど

**デフォルトの名無しさん** · 2024/03/21(木) 23:07:15.31

unsafeに手を出さなければ最悪でも暴走する前にpanicで停止する安全性は確保できる
実際は安全の為でもpanicで止まると困るから色々注意しないといけないし
unsafeで余計なチェック省いたり黒魔術使ったりもする
Rustの安全性のサポートは選択と集中がしやすくなる程度で万能ではない

**デフォルトの名無しさん** · 2024/03/21(木) 23:12:07.53

>>361
unsafeを使わなれば自動的に安全が保証される
unsafeを使うならその関連箇所に人間による安全保証が必要、それ以外は自動的に安全が保証される
C/C++はすべてのコードがunsafe状態なので自動的に安全が保証されるところがない

**デフォルトの名無しさん** · 2024/03/21(木) 23:22:25.34

いつもの人がきたｗ
結局レベルの低い人が書くとunsafeも不適切に使われて今回のように脆弱性が出てしまうでしょ
Rustであれば安全と思ってる人が多そうなのでかえってunsafeによる脆弱性が見落とされたり発覚しにくくなって問題だと思うんですけど

**デフォルトの名無しさん** · 2024/03/21(木) 23:58:23.31

> Rustであれば安全と思ってる人が多そう

いや一応言っとくけど多くはないよ流石にｗ
一部の人が連呼してるだけ
ほかの人はもっと現実的だろな

**デフォルトの名無しさん** · 2024/03/21(木) 23:59:21.08

原則はunsafeを使うな！
これだけだ

理解できていてunsafeを使う場合も
とにかく閉じ込めろ！
専用のクレートを作れ
専用のモジュールを作れ
専用の型を作れ

**デフォルトの名無しさん** · 2024/03/21(木) 23:59:51.15

unsafe使わなければ安全

**デフォルトの名無しさん** · 2024/03/22(金) 09:16:28.77

まあ実際rustはコンパイル通ればいいの思想を強める傾向にはある。
それは意識して気をつけた方がいい。

**デフォルトの名無しさん** · 2024/03/22(金) 10:19:34.77

ロジックや言語仕様を考えずにコンパイルが通るまでひたすらいじくり回すタイプの人間は本当にいる。
チュートリアルすら読まずに書き始めてなんもわからんから教えてと質問サイトに投稿しちゃうやつはいる。
そういうやつは早めに脱落して欲しいし大抵は脱落していくんだけどどういうわけか生き残ってあらゆるところをワヤにしていく狂人がたまにいるんだよ……
普通に現実を見ながらちゃんと学べる人なら (たまにはミスることもあるだろうけど) 大丈夫だよ。

**デフォルトの名無しさん** · 2024/03/22(金) 11:58:26.79

>>358
0～127の範囲のみを取りうるようなEnumなら作れる
wasmiの例のように実行時にバッファサイズが変動するなら無意味だけど

サイズが変動する場合はget_uncheckedに必要な安全性の保証をsafe wrapperの中でやるのが基本
それができないならunsafeのままにして上位で安全性を保証させるようにしないといけない
>>359のやり方はそれができてないように感じる

**デフォルトの名無しさん** · 2024/03/22(金) 12:34:01.41

実行時に範囲が変動するといっても制御下にあるのだからindexがその範囲にある時のみ有効な型を実装すればよい
そうすればその型に対して常に安全にget_uncheckedを使える

**デフォルトの名無しさん** · 2024/03/22(金) 14:04:42.65

Rustは失敗言語

**デフォルトの名無しさん** · 2024/03/22(金) 14:10:55.04

今回の件でRustの安全性が確実になったのが興味深いよな
アンチが必死に探してきた問題も>>350でunsafe利用だった

**デフォルトの名無しさん** · 2024/03/22(金) 16:00:31.63

>>371
「indexがその範囲にある時のみ有効な型」の意味がよく分かってないけど
実行時に型の方でindex検査して無効時にpanic起こすなら普通にusizeでgetしてunwrapしようよ
unsafeにする意味がない

**デフォルトの名無しさん** · 2024/03/22(金) 17:14:19.13

>>374
実行時コストをかけないためにget_uncheckedを使うのが一般的
その代わりロジックでindexが範囲内であることを保証する(ことがてきる時に使われる汎用的な手法)

**デフォルトの名無しさん** · 2024/03/22(金) 19:27:28.32

Adaなら特定の範囲の型作れるみたいよ

**デフォルトの名無しさん** · 2024/03/22(金) 20:07:18.97

今回は範囲が固定ではなく変わり得る

**デフォルトの名無しさん** · 2024/03/23(土) 23:29:45.64

誰にでもunsafeが使えてしまうのが問題なのでは？
原則使えないくらいが、バカでも安全になるからRustの方向性に合ってる気がする。

**デフォルトの名無しさん** · 2024/03/24(日) 00:34:36.37

Rust の制限は機械的に検証可能な範囲に絞ったらそうなったということであって、その制限の範囲内で十分にプログラムが書けるというものでもない。
まあ思ったよりも足りるけどやっぱり必要だから unsafe はある。

**デフォルトの名無しさん** · 2024/03/24(日) 10:55:06.56

>>375
「indexがその範囲にある時のみ有効な型」でも有効範囲が実行時に変動するなら>>350の引数のindexをその型に変えたところでsafeにしたらダメだよ

**デフォルトの名無しさん** · 2024/03/24(日) 11:08:34.82

なるほど、欲しい機能を実装していったら、結構安全になったって感じなのかな。OpenBSDみたいな偏執なのとは違う感じか？

**デフォルトの名無しさん** · 2024/03/24(日) 11:48:11.45

indexの境界チェックが律速になるようなコード書いてみてえな

**デフォルトの名無しさん** · 2024/03/24(日) 20:37:14.59

>>376 型宣言の時に type My_Int is range -1 .. 5; 範囲宣言(マイナスでも、１からでもＯＫ)できて、範囲を越えたらエラー　配列もその範囲指定で自由に作成できる。

**デフォルトの名無しさん** · 2024/03/24(日) 20:45:58.90

>>383
定数じゃなければ結局実行時にチェックするってことだよね

**デフォルトの名無しさん** · 2024/03/25(月) 01:12:47.74

>>384
新しい型はint型とは独立した型なんだから変数にしたってその新しい型じゃないとコンパイル時にエラー。

**デフォルトの名無しさん** · 2024/03/25(月) 07:21:41.59

>>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;

**デフォルトの名無しさん** · 2024/03/25(月) 14:37:28.19

今回の話は実行時境界チェックを無くす(減らす)実行時コスト削減の話だけど
そのAdaの例だと実行時に範囲外に値が動けてアクセスで例外発生するから何の解決にもなっていないね

**デフォルトの名無しさん** · 2024/03/25(月) 16:23:44.40

How much does Rust's bounds checking actually cost?
https://blog.readyset.io/bounds-checks/

**デフォルトの名無しさん** · 2024/03/25(月) 17:27:16.04

こんなもんjavaの速度低下が境界値チェックによるものじゃないってことで話は終わっとると思ったけどな。
問題は浮動小数の取り扱いだっての。

**デフォルトの名無しさん** · 2024/03/25(月) 21:23:48.62

unsafeは可能な限り避けるべきで
safe Rustでの改善をまずすべき
その次にindex checkの有無で意味のあるパフォ向上がある時のみ考える

現実にはsafe Rustでの改善ができてないことが多い
例えばよく見かける例としては
iが動いていくのにa[i]でアクセスしてしまう
これはiの範囲checkとa[i]の範囲checkで二重checkになるbad pattern
参照(ポインタ)化することで範囲checkを1回に減らせる

**デフォルトの名無しさん** · 2024/03/27(水) 15:06:55.14

unsafeは極力避けろというアドバイスばっかりでunsafeを適切に閉じ込める基本的な考え方や実装パターンの啓蒙が不十分なんだよね

unsafeを良く知れば知るほど自然と避けるようになるから避けろ避けろと言うよりもunsafeに関する知識を深められるようにする方が大事

**デフォルトの名無しさん** · 2024/03/27(水) 15:29:03.70

「unsafeの閉じ込めにはセンスがいるから、教えてもらわないと出来ないやつはunsafeを使うな」
が言える限界な気がする。現にunsafeを適切に閉じ込めるためのノウハウを継承できる資料とかがないので

**デフォルトの名無しさん** · 2024/03/27(水) 16:02:47.08

unsafeはライブラリ作者とかがハード周りアクセスするために使うもので、コーダーが使うものじゃないだろ。

unsafe可能ソースファイル用の拡張子を別途用意して、rsファイルはunsafe禁止にしてもいいくらいじゃない？

**デフォルトの名無しさん** · 2024/03/27(水) 16:59:36.71

>>393
そしたら全部を unsafe 可能版で書いちゃうのが世の中の現実ってもんなんだよ。

**デフォルトの名無しさん** · 2024/03/27(水) 17:05:39.09

>>392
センスの問題ではないと思うが仮にセンスが必要だとしてもセンスがあるやつが適切に閉じ込めた事例とダメな事例を類型化してパターンナレッジとして浸透させればいいだけ
今はそれが全然できてないから>>350のような基本的なミスを犯すやつが後を絶たない

**デフォルトの名無しさん** · 2024/03/27(水) 17:08:09.55

windows-rs とか使うと絶望するよな。もうちょいラップして安全なAPIも提供してほしい。

**デフォルトの名無しさん** · 2024/03/27(水) 18:09:17.85

>>395
～すればいいだけって言う奴はたいてい本人はやらないんだよなぁ。

**デフォルトの名無しさん** · 2024/03/27(水) 18:27:03.05

>>397
問題点の指摘や解決策の提案と
問題解決のために実際に誰が動くのかという
2つの異なるものを混同したらだめだよ
マネジメント101

**デフォルトの名無しさん** · 2024/03/27(水) 18:54:43.86

その素晴らしい提案がなぜされていないのか考えよう
そしてなぜ自分は実行から逃げているのか考えよう

**デフォルトの名無しさん** · 2024/03/27(水) 20:42:45.86

>>394
Rustが流行りそうな一番の理由は「管理側」が「コーダー」にunsafeみたいなことをやらせたくないということなんだから、どこでもunsafeとか管理側が許さんだろ。

**デフォルトの名無しさん** · 2024/03/27(水) 21:06:58.89

unsafe はコンパイラが安全性を「論理的に検証できない」部分であって、理論上の都合で出来た区分だよ。
危険な操作も含まれるけど危険な部分を分けれてるわけではない。
もちろん unsafe を制限する規約のプロジェクトがあったって良いが、そのための機能じゃないよ。

**デフォルトの名無しさん** · 2024/03/27(水) 21:18:47.87

>>401
安全性をコンパイラが検証できないなら、なおのこと制限すべきだと思うがね。
デフォルト禁止でもいいくらい。

**デフォルトの名無しさん** · 2024/03/27(水) 21:31:01.25

>>402
だからそうしたいならそうすりゃいいって話をしてる。
あなたが裁量権をもつプロジェクトでは。
私が反論してるのは「そのためのものだ」という部分に対して。

**デフォルトの名無しさん** · 2024/03/27(水) 21:44:58.62

>>403
Rustのコンセプトとニーズからすれば、どこでもunsafe使えるのは中途半端だ、ということだよ。
unsafeはデフォルト禁止でいいよ。

**デフォルトの名無しさん** · 2024/03/27(水) 21:49:49.48

理想をいえばunsafeなんて無いならサイコーだったんだろうね
rust陣営もしゃあなしでunsafe導入したんやろうし
unsafeなしですべてがセーフで効率的だったら
そりゃあrustは本当に素晴らしい文句なしの言語だったやろな

**デフォルトの名無しさん** · 2024/03/27(水) 22:08:33.46

生ポインタすなわちCPUによるメモリアクセスはunsafe
そこが出発点

unsafeを組み合わせてunsafeを閉じ込めたsafeなインタフェースを提供できる
それがsafe Rustの基本原理

つまりunsafeに行き着くためunsafe無しでは何もできない
これが真理

一方で
unsafeを閉じ込めたライブラリ利用可を前提にすれば
unsafeを用いないsafe Rustでほとんど大抵のことが実現できるのも事実

**デフォルトの名無しさん** · 2024/03/27(水) 22:24:02.18

>>406
だったらデフォルトunsafe禁止で良い。
どこでもunsafe okはやっぱりチグハグ。

**デフォルトの名無しさん** · 2024/03/27(水) 22:52:47.09

そこまでsafeな事にこだわるなら、Haskellに行けばいいのでは…？

**デフォルトの名無しさん** · 2024/03/27(水) 22:57:38.14

>>404
「そうであって欲しいと自分は思っている」なら別にいいよ。
ニーズとかコンセプトとか、ありもしないものを根拠にしてることに反論されてるんだよ。

**デフォルトの名無しさん** · 2024/03/27(水) 23:02:28.02

#![forbid(unsafe_code)]
を宣言すればいい

もちろんすべてはunsafeへ行き着くため
unsafeを禁止できるのは自分のコード部分だけ

**デフォルトの名無しさん** · 2024/03/27(水) 23:55:45.93

unsafeな部分の拡張子を変えるというのが有効とはあんま思えんのだよな
平気でunsafe使ってくるガイジは当然平気でunsafeな拡張子を使ってくるだろうという予想する

**デフォルトの名無しさん** · 2024/03/28(木) 07:44:09.91

>>409
公式の「効率的で信頼できるソフトウェアを誰もがつくれる言語」に従うなら、安全でもなくて誰もが使えるわけでもないunsafeはデフォルト禁止にすべきだろ。やっぱりチグハグだわ。

>>411
拡張子以外だとどんなのができるかねぇ。コーダー向けRustとライブラリアン向けRustで完全に分けるぐらい？

**デフォルトの名無しさん** · 2024/03/28(木) 08:15:17.48

rustもいろいろ問題を抱えてるんだね
プログラマの習熟が必要だっていうなら流行らないだろう
メモリ安全なソフトウェア書くことを優先するなら土方が適当に使えるjavaやc#があるだろうし
新しいc/c++/rustと競合する決定版のような言語が出てきてrustはさらなる傍流に押しやられそう

**デフォルトの名無しさん** · 2024/03/28(木) 08:34:31.08

>>412
こう書くだけでunsafeの使用が禁止されます
#![forbid(unsafe_code)]

>>413
普通の人はunsafeなんか使いませんからRustは安全で何も問題ありません

**デフォルトの名無しさん** · 2024/03/28(木) 08:48:28.49

>>414
>411みたいなマキャベリガイジが混ざると破綻しますな。
MSとかGoogleとかの管理側がRustに期待するのはそういった部分含めた安全性だろ。

**デフォルトの名無しさん** · 2024/03/28(木) 09:00:19.29

>>415
これでunsafeが使用禁止となり安全なsafe Rustになる
#![forbid(unsafe_code)]
コンパイラがunsafeをエラーとして弾く

**デフォルトの名無しさん** · 2024/03/28(木) 10:37:24.50

結局いつもの「無知なアンチ vs 無知な信者」の薄っぺらい対立になっちゃうのな

**デフォルトの名無しさん** · 2024/03/28(木) 14:03:58.90

まあハスケルなんかもinvalidな変数使うようにっての広めるのには役立ったからrustもそういう位置に落ち着くだろ。

**デフォルトの名無しさん** · 2024/03/28(木) 17:41:01.08

unsafeを使う人はライブラリ作成者がほとんどで、残りはシビアなインフラ作成者
一般プログラマーはunsafeを使わずに、unsafeが閉じ止められたライブラリのsafeなインターフェースのみ用いる

もしunsafeを用いて閉じ込めてsafeなインターフェースを提供できる新たなパターンを発見した時のみ、
その部分だけを切り出してライブラリ作成者になれる
それができない一般プログラマーはunsafeに縁がなく、unsafeを気にする必要がない

**デフォルトの名無しさん** · 2024/03/28(木) 18:27:15.03

>>419
そうならやっぱりデフォルト禁止にすべきだな。一般コーダーはunsafeを使えないようにしてコードの安全性を高めるべき。

Rustのデフォルトムーブとかshared xor mutableとかは安全側に倒しているのに、なんでunsafeだけはユルユルなのかね。

**デフォルトの名無しさん** · 2024/03/28(木) 18:35:39.73

unsafeって書かないといけないってのは結構デフォ禁止よりの処置だと思うが
このメッセージが伝わらない相手にはもうunsafeの文法を分けてunsafeだけ難しくするとかしかなさそう

でもわざわざ難しい文法を用意すると言うのも馬鹿らしい話だ

**デフォルトの名無しさん** · 2024/03/28(木) 18:56:54.80

必要な各企業、各プロジェクトなどで義務付け
#![forbid(unsafe_code)]
これでunsafeの話はおしまい

他の言語と比べてRustはコーディング規約もAPI規約も公式で楽
Rust公式APIガイドライン
https://rust-lang.github.io/api-guidelines/

**デフォルトの名無しさん** · 2024/03/28(木) 19:45:10.84

>>422
公式のドキュメントで
#![forbid(unsafe_code)]
の説明を探しているんだけど、どこにあるのかしらん？
doc.rust-lang.org/nomicon/safe-unsafe-meaning.html
の１行でおしまい？

**デフォルトの名無しさん** · 2024/03/28(木) 20:08:10.91

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

**デフォルトの名無しさん** · 2024/03/28(木) 21:59:19.02

Rust Foundationによる資格認定試験に合格した者だけにunsafe使用パスワードが発行されるようにするしかないな。

**デフォルトの名無しさん** · 2024/03/28(木) 22:34:58.42

どの開発でも
#![forbid(unsafe_code)]が原則

どうしてもunsafeが必要なら
その安全ロジックを関係者で協議後に
#![deny(unsafe_code)]へそのモジュールのみ変更し
許可する部分のみを
#![allow(unsafe_code)]として監視対象
といった感じが一般的かと

監視対象を極一部に限定できて
全体はコンパイラにより保証できるため
他のプログラミング言語より扱いやすい

**デフォルトの名無しさん** · 2024/03/28(木) 22:41:56.41

>>420
一般とそうでない奴は誰がどうやって区別するのさ？

**デフォルトの名無しさん** · 2024/03/28(木) 22:42:31.88

>>421
正解

**デフォルトの名無しさん** · 2024/03/28(木) 23:58:52.21

時間がない時はunsafe使っていいよ

**デフォルトの名無しさん** · 2024/03/29(金) 00:05:51.94

時間がない時に焦ってunsafe使って書いたコードは長期利用すると大変なことになるので書いてから1時間以内に使って捨てよう

**デフォルトの名無しさん** · 2024/03/29(金) 00:19:58.75

>>429
safeで書くのが早くて楽で安全
わずかでもパフォ上げる必要性のあるような箇所が生じない限り、unsafeを検討する人は存在しない

**デフォルトの名無しさん** · 2024/03/29(金) 00:24:32.79

>>430
unsafeの使用は、その論拠の安全性の検討や、それ以前に必要性の検討などが必要となるため、時間がかかる
safe Rustが楽で早く書けて安全

**デフォルトの名無しさん** · 2024/03/29(金) 01:57:50.63

壊れたレコードオジ怖い

**デフォルトの名無しさん** · 2024/03/29(金) 02:36:16.29

>>432
安全性の検討も必要な検討も全部スキップして「えいや」ってやればsafe rustより速く書き上がることもあるのでは？

**デフォルトの名無しさん** · 2024/03/29(金) 07:36:27.65

雑にunsafe使って早く書けるのはFFIくらいかな
FFIはどのみちunsafe必須だけど、事前条件とかの検討せずに雑にsafe化してしまうならそれは確かに早い
pure Rustでunsafeの方が早いケースはちょっと思いつかないな

**デフォルトの名無しさん** · 2024/03/29(金) 08:25:13.35

>>427
そりゃプロジェクト管理者だろ。
そもそもRust採用するメリットはソースコードの品質管理しか無いし。

デフォルトunsafe禁止は何回か話題に出てきているのな。

**デフォルトの名無しさん** · 2024/03/29(金) 08:27:22.40

>>426
それぐらいやらないとRust採用するメリット無さそうだよな。

**デフォルトの名無しさん** · 2024/03/29(金) 08:41:03.04

初心者ぼく「禁止しないといけないようなもんが標準で使えるって結局それ危険な言語なんでは？

**デフォルトの名無しさん** · 2024/03/29(金) 09:16:34.82

そもそも普通に書いててunsafe使いたいなって場面がない
多人数で書いてるならforbidで落としてもいいけど
コードレビューでちょっとでも見ればunsafe使ってることは明らかなんだし、いずれにしてもどうでもいい