Rust part14

**デフォルトの名無しさん** · 2022/02/12(土) 01:24:16.59

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

Web上の実行環境
https://play.rust-lang.org

日本語の情報
https://rust-jp.rs/

※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/

※C++との比較は専用スレへ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

※次スレは原則>>980が立てること

前スレ
Rust part13
https://mevius.5ch.net/test/read.cgi/tech/1636247099/

**デフォルトの名無しさん** · 2022/03/11(金) 04:20:44.43

>>366
Googleなんて言語オタクの精神異常者集めた企業の代表じゃん。そりゃそうなるよ。Common Lispとか好きそう

ジェネリクスとかイテレーターがなくてガッカリしてるのも言語オタクの特徴だな。普通の人はそれでいいって思ってるよ

**デフォルトの名無しさん** · 2022/03/11(金) 05:51:22.53

ほんとこのおじさん言語叩けりゃ何でも良いんだな。今度の棒はGoか。んでまだCommonLispのこと根に持ってる。そしてホントは.NET好きなのは隠しきれてない

**デフォルトの名無しさん** · 2022/03/11(金) 06:14:29.85

標準ライブラリならOKだよ
入っていると入っていないでは雲泥の差がある
処理系が責任を持って開発する部分で、基本部分である以上、ユーザーが少なくてもunsafeでも最大限の品質が保証されるから
言語仕様開発や処理系側からすれば、そんなところを大きくすると言語自体が保証する安全性にケチがつきかねないから小さくしたい心情はあると思う
純粋にフットプリントは小さくしたいしね
ただスレッドや同期機構まで用意してるので、世の流れとして非同期くらいまでは標準にしないと扱いにくいとは思う
切り離しやすく決まってると嬉しい
他の言語との比較はRust自体の説明に必要でない限りこのスレではしない

**デフォルトの名無しさん** · 2022/03/11(金) 09:41:54.29

なんだ、コード見て技術的なこと話してたらな、て思って見に来たら、
他のスレと同じで言語があーだこーだ言ってるだけか
まあ5chはこんなもんか

**デフォルトの名無しさん** · 2022/03/11(金) 09:58:37.49

unsafeがあるからダメなんじゃない
unsefeじゃないところがsafeなのがRustの大発明

**デフォルトの名無しさん** · 2022/03/11(金) 11:23:22.26

曖昧な感想をダラダラ書くより、これを紹介したほうが有意義だろ。

安全と危険のご紹介
ttps://doc.rust-jp.rs/rust-nomicon-ja/meet-safe-and-unsafe.html

**デフォルトの名無しさん** · 2022/03/11(金) 11:54:34.16

とりあえず英語版の方が内容新しいんで、こちらへ
https://doc.rust-lang.org/nomicon/working-with-unsafe.html

このexampleの2番目の
if idx <= arr.len() {
なんかが典型的で、これ気付けません。直後にあるとおり、

”...This program is now unsound, Safe Rust can cause Undefined Behavior, and yet we only modified safe code. This is the fundamental problem of safety: it's non-local. The soundness of our unsafe operations necessarily depends on the state established by otherwise "safe" operations...."

なわけ。
テキストでは最終的に可視性を利用して局所化してみたいなハウツーを入れてるけど、それは対策方法であって、局所化できる保証はない。
人間にミスは必ずあるからね。
どう書けば安全か分かっていて、それを確実に守れるなら、人間はC/C++でもバグ1つなく完璧にコーディング出来るはずなんだよ。

ってわけで、Rust is ☢UNSAFE☢ !!!!

**デフォルトの名無しさん** · 2022/03/11(金) 12:12:51.12

>>373
紹介している内容と主張している内容が一致していないように思えますが
unsafeが一つでもあればunsafeだと主張してるのかな？

**デフォルトの名無しさん** · 2022/03/11(金) 12:18:09.85

>>374
unsafeに閉じ込めるのはプログラマの責任、ということだろ。

Rustがunsafe以外で未定義動作にならないことを保証しているんだっけ？

**デフォルトの名無しさん** · 2022/03/11(金) 12:25:34.38

Haskellに対してモナドで副作用してるから純粋関数型言語じゃねえって感じの主張してはるんやろ

**デフォルトの名無しさん** · 2022/03/11(金) 14:14:05.70

モナドが副作用起こしてるんじゃなくて実装系が副作用起こしてるんだけどね。
まああの辺の無駄な解釈学振り回すことばっかりな点は同じクソさを感じるわな。

**デフォルトの名無しさん** · 2022/03/11(金) 15:15:40.38

>>377
あぁすまん。雑だった

**デフォルトの名無しさん** · 2022/03/11(金) 16:22:44.16

言語の理屈の立て方とそれの実現の仕方はレイヤが違う話だし、
言語の話をする以上は言語の理屈を軸にするしかしょうがないじゃん。

**デフォルトの名無しさん** · 2022/03/11(金) 21:29:04.10

>>373
unsafeを用いて安全なコードを書いている部分に対してのみ
人間が注力することができるようになったRustは他の言語より進んでると理解できた？

>>375
unsafe以外ではRustは未定義動作(undefined behavior)がないことを保証

>>379
そこは理屈というか理論というか抽象的な概念で理解しておくべきところだね
実装や内部表現は変わりうるし最適化で消滅しうるので実現方法で理解しようとしても不安定で無意味

**デフォルトの名無しさん** · 2022/03/11(金) 23:04:07.65

>>380
何度言っても「unsafeを用いて安全なコードを書いている部分」が人間には限定できないのを理解できてないのはお前ｗ

**デフォルトの名無しさん** · 2022/03/11(金) 23:23:27.18

>>367
Goが魅力的と書いておいてGoogleをそこまで叩くちぐはぐさ
Rustを叩ければ棍棒は何でもいいんだな

>>381
まだ意味不明なこと言ってRust叩きしてるのか
敗北を認められなくて引くに引けずかね

**デフォルトの名無しさん** · 2022/03/11(金) 23:25:07.91

>>382
叩く・叩かないや敵味方のような二つでしか考えられないのか？

**デフォルトの名無しさん** · 2022/03/11(金) 23:29:38.47

>>382
論理的に反論されたことがないという認識なんだがｗ
上から頭ごなしにこうです！と言われて、いやこうこうこういう理由でそうとは思えないと伝えたら、
「意味不明」とか「Rust叩き」とか、「敗北を認められな」いと言われて議論が終わっちゃうだけｗ

**デフォルトの名無しさん** · 2022/03/11(金) 23:30:30.36

>>383
自分が何を書き込みしたのか見直そうぜ

>>365
>>普通の人普通の企業にとってはGoの方が魅力的に映るだろうな

>>367
>>Googleなんて言語オタクの精神異常者集めた企業の代表じゃん

**デフォルトの名無しさん** · 2022/03/11(金) 23:32:12.74

>>385
叩いてみんなに構ってほしいだけなんだかほっとけ

**デフォルトの名無しさん** · 2022/03/11(金) 23:33:05.04

>>385
両方ともただの事実だが

**デフォルトの名無しさん** · 2022/03/11(金) 23:37:39.97

>>384
Rustの言語ルール及びunsafeとそれ以外(safe)を分けることで
初めてコンパイラが通れば安全性を保証すること成功した枠組みを
未だに理解できずイチャモンつけるだけしか出来なくて恥ずかしくないのかね？

**デフォルトの名無しさん** · 2022/03/12(土) 00:00:00.86

>>388
別にunsafe自体はRustが作ったわけじゃないよｗ
C#が大昔にunmagedなコードを呼び出すために開発した
Rust同様に別にどこまでも範囲は広げられる
Javaもnativeってあるよね

この2つは基本的にVMが保証している枠組みを外れる部分に対して使用されてるので、VM内のコードが実行される限り、使う動機が発生しない
対してRustは安全を担保するための所有権の仕組みを逃れるためなど、unsafeを使用する動機がいたるところにある
標準が提供しているライブラリが足りないこともあり、これは相当深刻な状況なわけだｗ

すると、両者が意味するunsafeな部分の意味が大きく変わってくる。
簡単に言えば原則safeな部分を書き換えるためにunsafeが使用されないかどうかの違いｗ
残念ながらRustは安全を担保するための所有権の仕組みを逃れるためなどの理由でsafeな部分を書き換えるためにunsafeが使用されてしまっている
Rustがunsafeな理由の1つはこの動機の部分に潜在的な問題があるってことｗ

**デフォルトの名無しさん** · 2022/03/12(土) 00:07:08.44

unsafeの話はマジで意味不明なイチャモンでしかないな
25860の方がよっぽどやべえだろっていう

**デフォルトの名無しさん** · 2022/03/12(土) 00:10:33.34

>>389
Rustはデータ競合やメモリの安全性を保証する
しかしJavaもC#も保証することはできず無関係
Rustよりも優れたプログラミング言語を持ってこないとこの件でRustを批判するのは無理

**デフォルトの名無しさん** · 2022/03/12(土) 00:11:14.62

>>389
tokioやmioがunsafe使ってるのは所有権の仕組みを逃れることが主な理由だと思っている？

**デフォルトの名無しさん** · 2022/03/12(土) 00:40:06.84

unsafeはなければ未定義動作が発生しないと仮定できるｗ
RustだけでなくVMで動いてるものは当然メモリ安全だって仮定できるｗ
Rustの場合は特性としてnativeであり所有権に制限を付けることで、パフォーマンスへの影響が少ない形で安全を仮定でき、さらにデータ競合がないことも仮定できるのが有利なところｗ
ただ、unsafeがあるだけでそこは無制限に全て瓦解してしまうんだよねｗ
そして付けた制限に対する回避のためにunsafeを使用するという潜在的な問題があり、さらに標準の機能不足により、unsafe増加が加速し、収拾がつかない大☢UNSAFE☢時代に突入しているわけだｗ
Rust is ☢UNSAFE☢! おーまいが!

**デフォルトの名無しさん** · 2022/03/12(土) 00:42:18.98

Rustが安全だというなら、cargo geigerで☢がない状態にしてから言ってくださいねｗ

**デフォルトの名無しさん** · 2022/03/12(土) 04:41:10.84

cargo geigerの存在がRustがベターであることを証明してて笑える

**デフォルトの名無しさん** · 2022/03/12(土) 05:34:45.69

そういうのは他の言語なら機能性だけで分かるし、nativeならnativeで閉じてるから安心できるんですよね
でも何度も言うようにRustは何をしなくとも自らunsafeを入れてしまうので調べないと分からないｗ
しかも使い方的にその場所だけに閉じないため、☢UNSAFE☢を実感できてしまうとｗ

**デフォルトの名無しさん** · 2022/03/12(土) 05:59:42.83

なんかやばい奴いるね

**デフォルトの名無しさん** · 2022/03/12(土) 06:05:00.96

かまってちゃんおじさんだよ

**デフォルトの名無しさん** · 2022/03/12(土) 06:28:17.65

ついにただ煽るだけの人まで現れたｗこれがRust品質ｗ

**デフォルトの名無しさん** · 2022/03/12(土) 07:31:15.18

C#おじ芸風変えてきたの？

**デフォルトの名無しさん** · 2022/03/12(土) 07:37:25.45

どのレスを指してるのか知らんが、俺を指して言ってるなら人違いｗ
ってか煽ってるだけで何もできなそうな奴多すぎｗ
芸風とかどうでもいいし、それを気にするならお前の芸風がキモいだけｗ

**デフォルトの名無しさん** · 2022/03/12(土) 07:38:35.78

人を煽るくせに自分が煽られるとすぐ被害者面するの、かまってちゃんおじさんの平常運転です

**デフォルトの名無しさん** · 2022/03/12(土) 07:45:19.39

ID変えて大変だねｗ

Run cargo-geiger!
💀💀💀☢☢☢☢💀💀💀 !!!! Rust is ☢UNSAFE☢ !!!! 💀💀💀☢☢☢☢💀💀💀

**デフォルトの名無しさん** · 2022/03/12(土) 08:05:59.99

必死だな

**デフォルトの名無しさん** · 2022/03/12(土) 08:10:52.33

流そうとして必死なのはお前ｗ俺はもう飽きてるぞｗ

Run cargo-geiger!
💀💀💀☢☢☢☢💀💀💀 !!!! Rust is ☢UNSAFE☢ !!!! 💀💀💀☢☢☢☢💀💀💀

**デフォルトの名無しさん** · 2022/03/12(土) 08:13:04.53

そこまでして構ってほしいのか

**デフォルトの名無しさん** · 2022/03/12(土) 08:13:48.07

あーあ壊れちゃった

**デフォルトの名無しさん** · 2022/03/12(土) 08:14:09.67

飽きすぎたわｗ

Run cargo-geiger!
💀💀💀☢☢☢☢💀💀💀 !!!! Rust is ☢UNSAFE☢ !!!! 💀💀💀☢☢☢☢💀💀💀

**デフォルトの名無しさん** · 2022/03/12(土) 08:23:02.74

荒らしにとって一番辛いのは叩かれることじゃなくて無視されること
NGにすればいいけど、もっといいのは違うかまってちゃんを全員が構うようになるとそうとう辛いw

**デフォルトの名無しさん** · 2022/03/12(土) 08:24:36.31

荒らしじゃないんだよなぁ・・・俺だけだよ。本当にRustの話してるのｗ

Run cargo-geiger!
💀💀💀☢☢☢☢💀💀💀 !!!! Rust is ☢UNSAFE☢ !!!! 💀💀💀☢☢☢☢💀💀💀

**デフォルトの名無しさん** · 2022/03/12(土) 08:33:16.69

> もっといいのは違うかまってちゃんを

複製おじですか

**デフォルトの名無しさん** · 2022/03/12(土) 08:35:57.42

やっぱワッチョイ入れるべきだったんだよ

**デフォルトの名無しさん** · 2022/03/12(土) 08:44:33.37

もう20レスくらい俺以外Rustのラの字もないなｗ

ワッチョイ入れてもねぇｗ NGとかなかなかしないんよねｗしかも俺結構大手のプロバイダだから多分被るよｗ
俺には関係ないからどうでもいいけどｗ

Run cargo-geiger!
💀💀💀☢☢☢☢💀💀💀 !!!! Rust is ☢UNSAFE☢ !!!! 💀💀💀☢☢☢☢💀💀💀

**デフォルトの名無しさん** · 2022/03/12(土) 08:52:13.10

ワッチョイ入れてほしくないんだね

**デフォルトの名無しさん** · 2022/03/12(土) 09:02:02.69

ワッチョイなんて俺には何の関係もないんだがｗ
俺が言うのもなんなんだが、Rustに関係のない話はやめた方がええでｗ
現状Rustというゴミ言語は俺にすら有効性を認めさせられないってことで、世間に広まるのは夢のまた夢なんだよなぁ・・・

Run cargo-geiger!
💀💀💀☢☢☢☢💀💀💀 !!!! Rust is ☢UNSAFE☢ !!!! 💀💀💀☢☢☢☢💀💀💀

**デフォルトの名無しさん** · 2022/03/12(土) 10:04:24.24

Rustが一部の高齢（脳年齢）エンジニアを狂わせるunsafeな言語であることが示されつつあるな
Rustがunsafeなのか高齢エンジニアがunsafeなのかは意見が分かれそうだが導入するときは要注意かもしれない

**デフォルトの名無しさん** · 2022/03/12(土) 10:13:42.44

裏ではtokio使って、非同期でも何でも簡単に使えます！安全です！とか他スレでホラ吹きまくってるからだろｗ
嘘をついてまで他スレに喧伝までしてなければ誰も叩いたりはしない

Run cargo-geiger!
💀💀💀☢☢☢☢💀💀💀 !!!! Rust is ☢UNSAFE☢ !!!! 💀💀💀☢☢☢☢💀💀💀

**デフォルトの名無しさん** · 2022/03/12(土) 11:04:21.69

実際はRust以外がunsafeで、Rustは一部safeなところがあるだけだけどね
高齢者はみんなcでunsafeに慣れてるから、Rust使わんでもunsafeだよ

**デフォルトの名無しさん** · 2022/03/12(土) 11:20:44.14

rustだけやってりゃいいとか言ってる奴は１００％老害化するよ。

**デフォルトの名無しさん** · 2022/03/12(土) 12:04:42.93

Rust以外がunsafeは嘘ｗ C/C++などの古い言語は全部unsafe ｗ
ただRustもunsafeな領域を人間には確実に限定できないので、☢があれば実質全部unsafe ｗ

Run cargo-geiger!
💀💀💀☢☢☢☢💀💀💀 !!!! Rust is ☢UNSAFE☢ !!!! 💀💀💀☢☢☢☢💀💀💀

**デフォルトの名無しさん** · 2022/03/12(土) 12:18:34.97

>>420
無知すぎるな
geigerは標準ライブラリを調べていない
そしてRustの標準ライブラリの中はもちろんunsafeだらけ
それなのにgeigerは一番肝心な標準ライブラリを調べていない

それはなぜか？
unsafeの正しい使用には全く問題がないからだ
unsafeを使ってそれを内部に閉じ込めて外部に安全なインタフェースのみ提供する
標準ライブラリを含めてライブラリはこの安全なインタフェースを提供している

**デフォルトの名無しさん** · 2022/03/12(土) 12:37:50.92

>>421
> geigerは標準ライブラリを調べていない
そんなことは>>316で書いたｗ
>>356 >>369でも言ってるとおり、ランタイム/VM＋標準ライブラリは「前提として」100%信用するｗ
この境界は区別しないとプログラム全体の安全性が定義できないし、それらの実装言語は何でもアリだからｗ

**デフォルトの名無しさん** · 2022/03/12(土) 12:45:28.26

rustは "安全な言語" じゃなくて "比較的安全なシステムプログラミング言語" だよ
議論のポイントがずれている

**デフォルトの名無しさん** · 2022/03/12(土) 12:50:29.49

unsafeを混在させたくないなら自分で書けばいいだけだよ
その選択ができることが他所とは違うところ

**デフォルトの名無しさん** · 2022/03/12(土) 12:53:38.99

>>422
愚かだな
どのプログラミング言語においても標準ライブラリに問題が発見されて修整されてが繰り返されてきた
標準ライブラリとなっけられているからといって100%信用できるわけがない
そこには何も保証がない

一方でRustならば標準か否かに関係なく保証ができる
unsafeを利用して安全なインタフェースを作った部分のみ人間がチェックすればライブラリ全体の安全性はRustの言語が保証できる
Rust以外の言語はライブラリ全体を人間がチェックしなければならない
Rustがこの点で全ての言語に対して優れていることは誰の目にも明らかだ

**デフォルトの名無しさん** · 2022/03/12(土) 13:01:02.47

で、おまえその優れた言語で何か書いてんの？え？actixのサーバー？コマンドラインのプログラム？(笑)

**デフォルトの名無しさん** · 2022/03/12(土) 13:08:00.19

>>423
ずらしてるんだけどねｗ

>>424
残念ながら世の中の需要はそうなっていないから、>>335と言ってたわけだよｗ
分離できる言語は多いけどｗ

>>425
そこを保証するのは処理系側なんて、その言語の利用者側は100%信用するしかないんだよｗ
標準以外がunsafeを利用してたらもう終了ｗなんで理解できないのかなｗ

>>426
匿名掲示板でそういうのは聞かないだろ普通ｗお前が言ったらじっくりいろいろ聞いてやるよ(俺は言わないｗ)

**デフォルトの名無しさん** · 2022/03/12(土) 13:10:43.13

>>426
主要基本orミドルの書き換え
今はLi*uxというあるOSを全てRustで書き直すプロジェクトの統括責任者兼主席ブログラマやってます

**デフォルトの名無しさん** · 2022/03/12(土) 13:17:12.35

他所とは違う点は認めるのね

**デフォルトの名無しさん** · 2022/03/12(土) 13:22:49.30

>>429
そっちは読んでもいねーよｗ俺宛て以外読みたくないだろ面倒だからｗ
まあ返事はしなくても分かると思うけどｗ

**デフォルトの名無しさん** · 2022/03/12(土) 13:39:59.72

安全第一　品質第二

今日も一日ご安全に

**デフォルトの名無しさん** · 2022/03/12(土) 14:25:52.99

(unsafeじゃないから)ﾖｼｯ

**デフォルトの名無しさん** · 2022/03/12(土) 14:33:29.78

ﾖｼｯ!!
#![forbid(unsafe_code)]
fn main() { maybe_safe::read_address_4byte(0); }
※全文は>>321 参照

**デフォルトの名無しさん** · 2022/03/12(土) 14:34:41.57

>>312だったｗ

**デフォルトの名無しさん** · 2022/03/12(土) 14:42:01.36

>>434
その>>312を見たが作った関数がunsafeなのにunsafe宣言をしていない
ルールを守らずにunsafeを使用してはいけない
ルールもわからない初心者ならばunsafeを使うな

**デフォルトの名無しさん** · 2022/03/12(土) 14:48:42.84

>>435
前にも同じこと言われて
>>314
>>316
となり、以降まともな反論ないんだけどｗ
しかもこのやり取り何度目？ｗｗｗｗ

**デフォルトの名無しさん** · 2022/03/12(土) 14:49:50.97

次スレワッチョイつけてくれや
マジでうっとおしい

**デフォルトの名無しさん** · 2022/03/12(土) 14:53:48.90

#![forbid(unsafe_code)]
fn main() { maybe_safe::read_address_4byte(0); }

(unsafeじゃないから)ﾖｼｯ
　　　 ∧　　/ヽ
　　　/／￣￣＼|
　　 ∠＿╋＿＿〉
　　/　①八①　ヽ＿
　工ﾆf(_人_)ｴ二|′)ヽ
　　＼ヽヽノノノヘ |
⊂⌒)_＞―――′イ (＿)
　`ー､_ノ/￣ヽ　｜
　　＿|｜　 |　｜
　　(　人＿ノ　Λ
　　＼ス￣￣ﾚ-Λ ＼
　　(￣　)　/ /　＼ﾉ＼
　　￣￣　(　ヽ　＼_)
　　　　　　＼ノ
※全文は>>312参照

**デフォルトの名無しさん** · 2022/03/12(土) 14:59:12.25

だから、比較的安全、ということでいいでしょ
オフィシャルも含めてそれはみな承知のことだよ

**デフォルトの名無しさん** · 2022/03/12(土) 15:04:06.13

比較的安全という「希望的推測ができる」だけで、実際にはC/C++と全く変わらないｗ
前にも言ったけど、ミニマムなunsafe領域を含む「設計意図としてのunsafe」が示せるだけｗ

**デフォルトの名無しさん** · 2022/03/12(土) 15:17:24.76

全く変わらないというのは、同じものを同じ人がCとRustで書いたとき、問題が起きる確率は変わらないだろうということ？

**デフォルトの名無しさん** · 2022/03/12(土) 15:24:02.56

>>440
違いを理解しよう

C/C++では安全性の保証は無し
ライブラリ含めて全てのプログラムに対して相互に関係する影響について人間が全てチェックしなければならない

Rustでは言語がすなわちコンパイラが安全性の保証をすることができる
unsafeを使った部分のみその影響範囲が閉じていることを人間がチェックするだけでよい

**デフォルトの名無しさん** · 2022/03/12(土) 16:06:48.08

作り方の問題で言語の理解がしっかりしてればどちらも同じように出来るｗ
機械的な保証があるかないかが問題で、その分はunsafeがある時点で保証できなくなるだけｗ
ただし、Rustには作り方に制限があるため、その作法でC/C++が実装された場合の話にはなる、というだけの話ｗ
C/C++で作法を守らない部分の責任は人間側で負う必要があるｗ
C/C++とRustどちらも保証はできないｗ

**デフォルトの名無しさん** · 2022/03/12(土) 16:09:18.50

Unsafe使ってたらSafeじゃない理論ってC#でもFFI使ってたらUnsafeってことでいいの？

**デフォルトの名無しさん** · 2022/03/12(土) 16:28:56.66

C#はunmanagedなコード以外でunsafeを使用する動機がないので懸念点がない上に、外部の何かへのアクセスが前提で、managedなオブジェクトの書き換えはあまり発生しない。
例外的にmanagedなオブジェクトを書き換える場合でも、unmanagedコードがロジック自体を持たないのが普通。
他方Rustは所有権の制限を適用しない目的などでオブジェクトを書き換えるため、それ自体がロジックの一部となっている。
例えば他のライブラリやシステムコールを利用してるなど、明確に分かるものがあればまだいいが、そういうのがないただのデータ構造に対するロジックなどにもunsafeが適用されるため、利用者側からは想定すらできず、それらを発見するためのツールが必要になってる状況も踏まえ、事態は深刻である。
そして多すぎるunsafeのせいで、それらを利用者側が正確に分類・把握できない、もしくは気付いてすらいないのが現状ｗ
実験室向けの簡単なコードならそれでよくとも、製品レベルのコードでそれは致命的であるため、安易な「安全宣言」は悲劇しか生まないｗ

Run cargo-geiger!
💀💀💀☢☢☢☢💀💀💀 !!!! Rust is ☢UNSAFE☢ !!!! 💀💀💀☢☢☢☢💀💀💀

**デフォルトの名無しさん** · 2022/03/12(土) 16:29:32.03

C#はFFI使わなくてもぬるぽ（ぬるり？）できるから最初からunsafeかと
せぐふぉじゃなければセーフというなら話は別だけど

Rustはunsafeな範囲を可視化できてその範囲指定が正しいことを機械的に保証できるから
C/C++に比べて比較的安全（安全性を担保しやすい）って話なんだけど
0か100でしか考えない人間にはこの差が見えないのかもしれないな

**デフォルトの名無しさん** · 2022/03/12(土) 16:33:40.22

「Rustはunsafeな範囲を可視化できてその範囲指定が正しいことを機械的に保証でき」ないのですよｗ
機械的に保証できるのは俺の言い方だとミニマムな部分だけｗ

Run cargo-geiger!
💀💀💀☢☢☢☢💀💀💀 !!!! Rust is ☢UNSAFE☢ !!!! 💀💀💀☢☢☢☢💀💀💀

**デフォルトの名無しさん** · 2022/03/12(土) 16:39:30.29

変な言い回しするから言いたいことがよく分からない
自分でunsafe書いてなくても、依存関係がunsafeを濫用してたらアプリケーション全体としてはunsafeじゃないか
という主張なんだよねたぶん

**デフォルトの名無しさん** · 2022/03/12(土) 16:51:59.88

俺の主張の大事な点は2つだよ
・安全とするにはunsafeと宣言すべき関数を機械的に決めることが出来ない
・安全のために所有権に厳しい制約を課しているが、その厳しさからunsafeを使う動機が常に言語内にある

これらから導かれる推測は多岐にわたるけど、分かりやすい結論として
Run cargo-geiger!
💀💀💀☢☢☢☢💀💀💀 !!!! Rust is ☢UNSAFE☢ !!!! 💀💀💀☢☢☢☢💀💀💀
という警鐘を鳴らしているだけｗ

**デフォルトの名無しさん** · 2022/03/12(土) 16:57:57.83

一つ目言ってる意味がもう分からないんだけど
普通に言ってくれ

**デフォルトの名無しさん** · 2022/03/12(土) 16:59:02.17

わっチョイの議論が出てるけど個人的には過疎るから賛成できない
この人は語尾wでNGすればいいだけと思う

**デフォルトの名無しさん** · 2022/03/12(土) 17:05:16.49

>>450
普通に言った。何が分からないのか言ってくれｗ

**デフォルトの名無しさん** · 2022/03/12(土) 17:10:56.57

安全のために所有権に厳しい制約を課しているが、その厳しさからunsafeを使う動機が常に言語内にある

わからんでもないかもしれん

**デフォルトの名無しさん** · 2022/03/12(土) 17:38:29.48

＞・安全とするにはunsafeと宣言すべき関数を機械的に決めることが出来ない

安全とするには～する必要がある
なら分かるが、

安全とするには～出来ない
なので主張がわからんという話でしょ

**デフォルトの名無しさん** · 2022/03/12(土) 17:44:06.44

>>448
『自分でunsafe書いてなくても、依存関係がunsafeを濫用してたらアプリケーション全体としてはunsafeじゃないか
という主張』は
実際に使われているモジュールでそういう例があるならば成り立つ
しかし現実にはunsafeなモジュールは存在しなくて
>>445はその例を挙げることすら出来ていない
机上の空論を繰り返しているのみ

**デフォルトの名無しさん** · 2022/03/12(土) 17:47:55.25

>>453
その場合ですらunsafeは使っても構わない
そのunsafeを使った局所的な部分に影響が閉じ込められていて安全なインタフェースのみ公開されていればよい
そしてRustコンパイラは残り全体の安全性を保証できる

**デフォルトの名無しさん** · 2022/03/12(土) 18:12:42.07

いい加減無視することを覚えとけ
こんなの相手にするから調子乗るんだぞ

**デフォルトの名無しさん** · 2022/03/12(土) 18:22:27.94

>>454
(安全とするにはunsafeと宣言すべき関数)を機械的に決めることが出来ない
こう書けば分かるのだろうかｗｗｗｗ

>>455
issueがないとでも思ってるの？ｗｗｗｗ

>>456
「そのunsafeを使った局所的な部分に影響が閉じ込められてい」る前提がおかしいｗ
安全なインタフェースとは誰が判断するの？ｗｗｗｗ
どうなってたら安全なの？ｗｗｗｗ
それを人間が判断する以上、どこまでも間違いは起きるよｗ

Run cargo-geiger!
💀💀💀☢☢☢☢💀💀💀 !!!! Rust is ☢UNSAFE☢ !!!! 💀💀💀☢☢☢☢💀💀💀

**デフォルトの名無しさん** · 2022/03/12(土) 18:34:51.66

反応してるやつも同レベルの荒らしだから、いっしょくたにあぼーんしましょうね

**デフォルトの名無しさん** · 2022/03/12(土) 18:41:59.36

>>451
これが正解
末尾wは煽りたいだけだから対話する気がないし

**デフォルトの名無しさん** · 2022/03/12(土) 21:08:03.28

例えばTokioを使ってUnsafe由来の変な落ち方する例とかが有ればUnsafe使ったライブラリ全然信頼できねーなって同意すると思う

**デフォルトの名無しさん** · 2022/03/12(土) 22:12:28.43

与えられたコードがunsafeかどうかを判定するルーチンHがあればいいんだろ

**デフォルトの名無しさん** · 2022/03/13(日) 00:20:04.81

>>461
https://www.google.com/search?q=tokio+issue+unsafe
全部調べてないと証明できないのであればあるｗ
これ以外に存在しないかどうかは不明だが、お前が信用するしないで事実が変わるわけじゃないｗ

>>462
そうだね

Run cargo-geiger!
💀💀💀☢☢☢☢💀💀💀 !!!! Rust is ☢UNSAFE☢ !!!! 💀💀💀☢☢☢☢💀💀💀

**デフォルトの名無しさん** · 2022/03/13(日) 16:13:24.15

次スレはワッチョイつけますから覚悟しておいてください
それまでの命だ
せいぜい楽しむがいい

**デフォルトの名無しさん** · 2022/03/13(日) 16:28:13.28

>>463
読んでみました
・質問者がunsafeの言葉を使い間違えてました
・ランタイムを何度も複数回スタートさせていました　(そしてunsafeな状況は起きていない)
などで
(unsafeを使って)安全でないインタフェースを公開してしまったわけではないようです

>>464
反対です
過疎ってRustが不利になるだけなので
皆がワッチョイ無しスレも立てる結果となるでしょう

**デフォルトの名無しさん** · 2022/03/13(日) 16:46:41.64

>>465
皆というかあなたがね