Rust part25

**デフォルトの名無しさん** · 2024/07/31(水) 00:46:26.17

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

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

**デフォルトの名無しさん** · 2024/08/22(木) 20:23:18.57

>>351
ChromiumとChromeのC++メモリ脆弱性が日常茶飯事になってるから
少しずつRustへ置き換えていく方針なのか

**デフォルトの名無しさん** · 2024/08/22(木) 22:43:10.37

Firefoxはおっさんしか使っていない

**デフォルトの名無しさん** · 2024/08/22(木) 22:46:45.14

chrome 系一色になるのも良くはないからね。

**デフォルトの名無しさん** · 2024/08/22(木) 22:47:07.99

Rust信者からするとこの期に及んでC++でブラウザの再実装なんて始めやがったLadybirdのことは全力で呪ってる感じ？

**デフォルトの名無しさん** · 2024/08/22(木) 22:57:32.73

chromiumがC++のメモリ管理ミスでセキュリティ脆弱性を毎回出し続けているように
ブラウザのような新機能を常に加えていく大規模ソフトウェアでC++の使用は無理がある
だからchromiumはRustを採用し始めた

**デフォルトの名無しさん** · 2024/08/22(木) 23:59:43.53

>>355
Ladybirdは作者が慣れてるから初期実装をC++でやっただけでSwift6.0が出たら移行みたいだよ
まぁRustのエコシステムに貢献してくれたほうが良かったとは思うけど、Swiftならいいんじゃないかな

**デフォルトの名無しさん** · 2024/08/23(金) 00:10:40.25

Swiftが遅い原因は
Rustで例えるとArc<Mutex<T>>を常用することでメモリ管理問題から逃げているため
という理解でいいのかな

**デフォルトの名無しさん** · 2024/08/23(金) 00:24:23.39

Chromeは生ポインタ使ってるところを
一気にスマートポインタ等に置き換えたという
話を何年か前に聞いたけどそれじゃダメなんだな

**デフォルトの名無しさん** · 2024/08/23(金) 09:32:17.32

&strはlowercaseﾌﾟﾙﾌﾟﾙ

**デフォルトの名無しさん** · 2024/08/23(金) 09:59:59.89

primitive type は小文字ってのは Java あたりを踏襲した感じなのかね？

**デフォルトの名無しさん** · 2024/08/23(金) 10:07:13.27

>>359
スマートポインタだけでは駄目で、 Rust で言うスライスみたいなものがないと安全に管理できない。
近年の C++ にはそういうライブラリも追加されたけどまだちょっと整備が不足している。
C++ は標準ライブラリには過剰なほど高い抽象度・汎用性を求めるので多次元のコンテナとの辻褄合わせでずっと議論してる……

**デフォルトの名無しさん** · 2024/08/23(金) 10:12:11.46

>>361
Cからずっとそうじゃないっけ？
組み込み型名はたいてい予約語で、予約語はたいてい小文字だからな気はする

**デフォルトの名無しさん** · 2024/08/23(金) 10:29:44.46

>>363
いや、暗黙の前提として「標準ライブラリの型名は camel case なのに」ってのを含んでる。
つまり「primitive とライブラリを違えている」ということを話題にしたくて、それを原則にしている言語の例として Java を挙げた。

**デフォルトの名無しさん** · 2024/08/23(金) 12:43:06.00

RustでcamelCaseは用いない
基本型は小文字
structやenumで作る型および別名はUpperCamelCaseを用いる

例えばstrは基本型だから小文字
StringはstructだからUpperCamelCase

**デフォルトの名無しさん** · 2024/08/23(金) 14:34:53.94

strって言うほど基本型か？問題

**デフォルトの名無しさん** · 2024/08/23(金) 15:29:42.74

https://users.rust-lang.org/t/why-is-str-a-primitive-type/36551
ふーん

Javaとは違ってprimitiveかそうでないかによる重要な違いはなくて、別に区別する必要性はそこまでないし、気にするだけ無駄そう
名前持ちのprimitive型の中でstrだけがDSTなのが違和感の正体かも

**デフォルトの名無しさん** · 2024/08/23(金) 15:49:44.63

array(記述は[T; N])やslice(記述は[T])やstrはもちろん基本型
そしてヒープを必要としない
だからcoreにありno_stdでも使える

一方でBoxやVecやStringはヒープを必要とする
だからcoreにはなくallocにある

**デフォルトの名無しさん** · 2024/08/23(金) 20:34:48.59

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=d8fa7bff7e61accb6f6bf7f0d4075dae

要素への不変参照を保ちつつ追加できるコレクションが欲しくて試しに書いてみたけど、どうすりゃいいんだ
UnsafeCell使うしかない？

**デフォルトの名無しさん** · 2024/08/23(金) 21:33:21.24

>>367
スライスとstrとdynはDSTだからこそprimitiveだよ
参照が他と異なりfatポインタになるからね
"あいうえお" を正規UTF8と定めた点もRustの良いところ
それをprimitiveな型strとしたのも良い判断だね

**デフォルトの名無しさん** · 2024/08/23(金) 21:41:42.80

>>369
それは単純に参照を借りっぱなしになってるエラー
どこまで何をしたいのかによるけど
そのコンパイルエラーを解消したいだけなら
Cons(T, Box<List<T>>)を
Cons(Rc<T>, Box<List<T>>)にして
Some(t)をSome(t.clone())すればよい
ちなみにUnsafeCellは内部可変性の源泉なので
そういう新たな汎用型を作る時に使うものでunsafeだよ
一般プログラマーは使ってはいけない

**デフォルトの名無しさん** · 2024/08/23(金) 21:46:56.38

名前に露骨に Unsafe って付いてるんだから十分な理解なしに使うのはやめておけという意図は感じるよな。

**デフォルトの名無しさん** · 2024/08/23(金) 21:47:30.17

>>370
UTF-32の方が単純で良かったんじゃないか？

**デフォルトの名無しさん** · 2024/08/23(金) 22:02:55.80

>>373
ファイルもネット通信もUTF8に統一されていってる状況だから
それらを無変換で済むUTF8がベストだよ
UTF32はメモリを無駄に消費してメリットがないよね

**デフォルトの名無しさん** · 2024/08/23(金) 22:05:42.82

UTF-8 はランダムアクセスに難があるが文字列のランダムアクセスってそんなに要らんだろという割りきりだな。
やりたければ UTF-32 用の型を使えるし、あくまでも言語の基本には UTF-8 を据えるってだけ。

**デフォルトの名無しさん** · 2024/08/23(金) 22:07:14.75

>>371
そこは一般プログラマーじゃないと仮定して、UnsafeCell使うならこんな感じでいいんですかね？
RustのUBにちょっと詳しくなくて

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=509935956fa3b81133414a9e19920557

**デフォルトの名無しさん** · 2024/08/23(金) 22:26:58.16

UnsafeCellは内部可変性を持つ安全な型を作るためのunsafeな部品として存在している
目的外に使う人に対しては今後は他の質問についても答えない

**デフォルトの名無しさん** · 2024/08/23(金) 22:27:06.29

>>376
値が数値だから今のところ問題ないけどこの実装だとListを新しいConsに突っ込んだ瞬間に
先頭の値の参照先が無効になりそうだな

自作にこだわらないならtyped-arenaを使うといい
https://docs.rs/typed-arena/latest/typed_arena/
小さいライブラリだから自作の参考にもなると思う
ライブラリ使わないならどこかでunsafeは必要になる

**デフォルトの名無しさん** · 2024/08/23(金) 22:50:35.38

ちょっとuser-friendlyに整理してみた
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=509935956fa3b81133414a9e19920557

>>378
ListNode<T>は絶対にBoxに包むようにして、itemはヒープ上のTを指してるので
unsafeの中で間違ってBoxをdropしなければ無効な参照は発生しないと思うんですが、どうなんでしょう

typed-arena!
存在は知ってたけど、RefCellと組み合わせてグラフをなんかいい感じに扱えるやつくらいの認識だったので完全に盲点でした
これでいけそうです、ありがとうございます

**デフォルトの名無しさん** · 2024/08/23(金) 22:55:03.65

おっとリンク再生成してなかった
ちょっとuser-friendlyに整理してみた版
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=b0ca47dce14c07da2936f1964bc54485

**デフォルトの名無しさん** · 2024/08/23(金) 23:21:46.23

安全だと思い込んでunsafeを使うやつはCでも使っとけ

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

依存クレートの中からunsafeを検索して一覧表示するようなツールある？

**デフォルトの名無しさん** · 2024/08/24(土) 00:11:50.62

数えるだけならcargo-geiger
ナンセンスすぎて使ったことないけど

**デフォルトの名無しさん** · 2024/08/24(土) 05:53:44.99

>>382
あまり意味がない気もする
actix-webの作者は「unsafe使うな」「それはRustのやり方ではない」という沢山の声にうんざりして開発停止する事件が起きた
unsafeは危険というよりも「このコードの安全性はコンパイラでは検証しないので実装者が責任を持つ」ブロックと考えて、よくテストされたライブラリについてならある程度信用して良いと思う

**デフォルトの名無しさん** · 2024/08/24(土) 07:54:28.69

unsafeは人間が安全性を保証しなければいけないため、必ず多くの監視者がいなければいけない。
そして不必要なコードと必要で安全なコードを皆で選別しなければならない。
パフォーマンスにほぼ影響なく無くせるケースは無くすべきというのが第一原則。

**デフォルトの名無しさん** · 2024/08/24(土) 07:56:32.18

一方でRustの標準ライブラリには何千ものunsafeが存在していて、安全なインターフェースを提供してくれている。
このおかげで我々はunsafeを使わずにパフォーマンスの高いコードを書くことができる。
標準ライブラリと同様に他のクレートでも下支えをしてくれるものは同じ立ち位置として認められているものが多い。
つまり必要不可欠なものである。
いずれにしてもライブラリ内に隔離して外向けに安全なインターフェースを提供してくれることが第一原則。

**デフォルトの名無しさん** · 2024/08/24(土) 08:06:32.30

Rust の参照についている様々な制約は機械的に解析可能なように制限したのであって
人間的な感覚での適切な抽象やデザインパターンと両立不可能な場合がある。
機械的検証可能性を維持するために不自然なデザインを持ち込むのが健全とは言い難いよ。

unsafe はなるべく低レイヤの小さな範囲に押し込めたほうが良いのは確かだが、
プロジェクトの性質によってはそれがもうちょっと高レイヤまではみ出してくることだってあるだろ。

**デフォルトの名無しさん** · 2024/08/24(土) 08:21:40.08

>>382
grep

**デフォルトの名無しさん** · 2024/08/24(土) 08:22:12.74

>>387
適切な抽象やデザインパターンと両立不可能な場合がある、ってマジ？
そんな話は聞いたことないな
具体的な例を教えて

**デフォルトの名無しさん** · 2024/08/24(土) 09:00:02.66

>>297
tauriがrustを基盤としたフレームワークなのだから
rustと特別な関係にあるservoに移行するのは必然では？

**デフォルトの名無しさん** · 2024/08/24(土) 10:45:01.27

servoが最低限まともに動くようになるには、あと軽く5年はかかる
今のバージョン動かしてみ？
夢見すぎ

**デフォルトの名無しさん** · 2024/08/24(土) 11:01:21.63

>>384
>unsafeは危険というよりも「このコードの安全性はコンパイラでは検証しないので実装者が責任を持つ」ブロックと考えて、よくテストされたライブラリについてならある程度信用して良いと思う
こういうスタンスはダメだよな
作ってるアプリによっては許される場合もあるんだろうけど

**デフォルトの名無しさん** · 2024/08/24(土) 11:31:23.33

>>390
俺はtauriのコアコンセプトはOSが提供するブラウザエンジンを使い、バイナリサイズやセキュリティアップデートの問題を解決することだと俺は思ってるんだ。
だからRust使ってるからservo使うってのは門外漢には自然に見えてもコアコンセプトを忘れてもともとの問題を解決しないOSSになっていってる感じがするんだよな。

**デフォルトの名無しさん** · 2024/08/24(土) 11:47:25.22

ブラウザエンジンの選択肢が増えるだけでしょ
wryの中のfeatureが増えるのかwryごとservoに差し替えるfeatureになるのかは知らんけど

**デフォルトの名無しさん** · 2024/08/24(土) 12:27:15.89

.NET 9の新機能としてC#版Tauriが来るらしい
Go版Tauriもあるらしいし、流行ってるのかな

**デフォルトの名無しさん** · 2024/08/24(土) 12:33:53.63

疎結合でブラウザを GUI として使うには接続部分を上手く標準化する必要がある。
参加が多いほど標準化の圧力が生まれるし、良いことだと思う。

**デフォルトの名無しさん** · 2024/08/24(土) 13:14:00.45

いまどき疎結合とか意味のないこだわりだな

**デフォルトの名無しさん** · 2024/08/24(土) 13:30:29.34

疎結合とかそういうかっこいい話じゃなくて
今どき新規にGUIツールキット作ってもウィジェット開発してくれる人が集まらないから
Web技術転用してしのぐかって話でしょ？

当のMicrosoftは3連続ぐらいで新GUIツールキットの開発に失敗しバグ残したまま撤退を繰り返してるし

**デフォルトの名無しさん** · 2024/08/24(土) 13:38:09.55

unicode の表示からしてウェブブラウザ以外は規格に追い付いてない感触はあるなあ……

**デフォルトの名無しさん** · 2024/08/24(土) 13:46:07.91

>>393
そう思うならforkすればいいのに
オープンソースなんだし
コード書かない人には一家言もない世界よ

**デフォルトの名無しさん** · 2024/08/24(土) 13:46:41.99

いまはネットワークが高速で繋がっている前提なのなw

**デフォルトの名無しさん** · 2024/08/24(土) 13:54:50.23

>>395
仕組みは組み込みWebViewをネイティブの上で起動してるだけだから作るのが大して手間じゃないし実装してみたって感じでしょ

**デフォルトの名無しさん** · 2024/08/24(土) 14:58:54.54

>>382
github

**デフォルトの名無しさん** · 2024/08/24(土) 15:01:04.10

>>387
＋１

**デフォルトの名無しさん** · 2024/08/24(土) 15:03:55.41

>>401
これホント困るわ

**デフォルトの名無しさん** · 2024/08/24(土) 16:36:29.92

>>400
いや、牛丼屋なのに鰻丼を中心にするんだ…みたいな気持ちがあるだけで、俺は現状 tauri に用はないので…。

ちゃんと使ってる crate はコントリビュートチャンスを伺ってるよ。

**デフォルトの名無しさん** · 2024/08/24(土) 16:50:25.05

unsafeブロックってどこからどこまで囲えば良いんだろう

**デフォルトの名無しさん** · 2024/08/24(土) 18:11:39.50

>>407
「可能な限り小さく」が原則

**デフォルトの名無しさん** · 2024/08/24(土) 18:18:35.56

Rustでunsafeは使ってはいけない
例外的にunsafeの使用が認められるのは以下2点のみ
ベテランが基盤クレートを提供する時
ベテランがFFI部分を記述する時

**デフォルトの名無しさん** · 2024/08/24(土) 18:20:35.25

unsafe なことをやっている箇所をなるべく小さい範囲で囲むべきだがお互いに関係のある複数の unsafe がごく近くにあるならまとめて囲むほうが分かりやすいということはあるかもね。

**デフォルトの名無しさん** · 2024/08/24(土) 18:29:15.33

そういうケースを除くとunsafeを使ってる者は技術力がないだけのバカと
パフォーマンスにほとんど変化しないのに高速化してるつもりで保守性を下げてるアホだからな

**デフォルトの名無しさん** · 2024/08/24(土) 18:32:37.91

Rustでどう書くのか分かりませんが、C言語で書けば、
BYTE *ConvertUintToPtr( Uint32 u ) {
　unsafe {
　　return (BYTE*)u;
　}
}
のような関数をRustで作ることは出来ますかね？

**デフォルトの名無しさん** · 2024/08/24(土) 18:33:08.29

>>408
最小限にするなら、>>380はこうしたほうがいいってことかね
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f27cd2a3b6b850770a839c17d6fe3ec4

unsafeブロックもブロックではあるから、通常のブロックと同様にdropが働くから、それに注意して無効な参照をsafe内に持ち出さないようにすればいいってことかね？

**デフォルトの名無しさん** · 2024/08/24(土) 18:43:12.73

>>406
現状だと
servo「うちの鰻丼を置かせてください！」
tauri「まぁ客に出せる味になったらメニューに加えてもいいよ」
くらいの温度感に見えるけどなぁ。これまでの発表はservo側からだし、tauriチームとしてservoに全面移行するなんて話は出てないと思うけど

**デフォルトの名無しさん** · 2024/08/24(土) 18:46:57.91

>>413
unsafeの作法も知らない雑魚はunsafe Rustを使うな
基礎から学んで出直してこい

**デフォルトの名無しさん** · 2024/08/24(土) 18:51:25.05

unsafe Rust使うくらいならCでよくない？
反対意見あったら言ってくれ

**デフォルトの名無しさん** · 2024/08/24(土) 18:52:59.44

>>412
当然できるけど
危険な行為なので熟練者とキチガイしか使わないよ

**デフォルトの名無しさん** · 2024/08/24(土) 18:53:02.17

>>415
一応Referenceのunsafe blockの部分は読んだけど、nomiconも全部読まなきゃだめ？
具体的にどこが間違っている/作法に反しているのか指摘してくれるとありがたいんですが……

**デフォルトの名無しさん** · 2024/08/24(土) 18:55:23.20

>>417
参考のため、どう書けばいいのか教えていただければ幸いです。

**デフォルトの名無しさん** · 2024/08/24(土) 18:55:51.72

>>416
反対意見なんてないよ
人間はバカだからC/C++ではなくRustを使わざるを得ない状況になってるんだし
なるべくならRustなんて使いたくもない

**デフォルトの名無しさん** · 2024/08/24(土) 18:57:28.86

>>416
インフラやFFI部分のライブラリを作る上級者は例外として
unsafeを使うのはキチガイばかりだね

**デフォルトの名無しさん** · 2024/08/24(土) 19:07:44.35

>>412
変換するだけならunsafeも特に要らなくて、ただのasキャストでいいみたいね
fn convert_uint_to_ptr(u: usize) -> *mut u8 {
u as *mut u8
}

これをやるだけの関数なら、まだstableじゃないけど標準ライブラリにもあるようで
安全にするためにstrict provenance rulesなる仕様を検討中な様子
https://doc.rust-lang.org/std/primitive.pointer.html#method.from_bits-1
https://doc.rust-lang.org/std/ptr/fn.with_exposed_provenance_mut.html

**デフォルトの名無しさん** · 2024/08/24(土) 19:24:20.93

ポインタは観測するまで安全

**デフォルトの名無しさん** · 2024/08/24(土) 20:06:41.28

逆参照しなきゃ安全
だけど大体はアドレスがわかってるならそれを指すポインタや参照もわかってるはずなのでアドレスをポインタにする機会はそんなにない

**デフォルトの名無しさん** · 2024/08/24(土) 20:08:48.83

>>392
そらそうやけど、それでうまく行くならC++でええやんいう話になるわな

**デフォルトの名無しさん** · 2024/08/24(土) 20:22:17.51

Rustに不慣れで技術力の低い人がunsafeを使う傾向が高い
ほとんどのケースは既存の安全なパーツを組み合わせるだけで安全に実装できる

**デフォルトの名無しさん** · 2024/08/24(土) 21:14:33.88

>>426
単発君
自分でunsafeを書く必要性がない書く気がないならそれでいいと思うし、その立場は理解したから、どうか他人の足を引っ張らないでくれ
unsafeの書き方を学ぼうという同志がいないのならそのうち去るから、すまないがそれまで待ってくれないか

**デフォルトの名無しさん** · 2024/08/24(土) 21:26:04.07

unsafe で UB になる場合を知りたい場合にはどこに仕様が書いてあるのかがそもそもわからん。

**デフォルトの名無しさん** · 2024/08/24(土) 21:26:45.92

UnsafeCellを使ってる頭のおかしな人のコードはborrow checkerに引っかかってコンパイルを通せないところから始まってるよね
unsafeの使い方を学ぶのではなくsafe Rustの使い方を学ぶべきかと

**デフォルトの名無しさん** · 2024/08/24(土) 22:11:07.05

>>428
現状のベストエフォートのまとめはこれですかねえ
LLVMのマニュアルなんて参照しちゃってるから、LLVM IRまでのloweringの詳細を完璧に把握でもしていない限りこれを一次資料として参考にするってのは無理そうですが……
https://doc.rust-lang.org/reference/behavior-considered-undefined.html

あとは呼んでいるunsafe fn/実装しているunsafe traitのドキュメント（当たり前）と、the Referenceをundefinedで検索した結果とかでいいんでしょうか

**デフォルトの名無しさん** · 2024/08/24(土) 22:14:58.07

既存の安全なパーツを使いこなせる熟練者であることがunsafeを書くための最低限の資格だ
これができないとunsafeを使うべきか否かという入口すら判断できない

**デフォルトの名無しさん** · 2024/08/24(土) 22:53:26.45

Rust のメモリまわりの動作モデルは結局は C/C++ に合わせることにしたみたいな話をどこかで見たようなおぼろげな記憶がちょっとある。
LLVM がなんだかんだで C/C++ を想定した形になってしまっているのとその辺の低レイヤの部分がちゃんとモデル化されている言語が C/C++ くらいしかないから Rust のためにあらためて検討するくらいならもう合わせちゃって良くない？みたいなニュアンスだったと思うんだけどどこで見たのかも思い出せないから違ってたらごめんね。

**デフォルトの名無しさん** · 2024/08/24(土) 23:22:54.73

>>422
有難うございます。
ところで、Rustでは、unsafe 以外では、専ら参照型が使われると思っていたのですが、
unsafe を使わない部分でも、ポインタ型 * が使えるようですね。
Rustにおけるポインタ型を参照型のアドレスに採用する方法も教えていただければ幸いです。
C++ であれば、
T x;　//xは、T型の変数。
T *p = &x;　//pは、T型へのポインタ型。アドレスは変数xのアドレス。
T &r = *p;　//rは、T型の参照型。
で、参照型rのアドレスがpの指すアドレスに一致しますね。

**デフォルトの名無しさん** · 2024/08/24(土) 23:31:10.68

>>433
生ポの参照外しはできない
生ポを参照にすることもできない
それらはunsafe

**デフォルトの名無しさん** · 2024/08/24(土) 23:50:29.93

>>434
では、C++であるならば、以下の様に書けそうなコードをRustで書くとすると
どうなるでしょうか。
BYTE &ConvertPtrToRef( BYTE *p ) {
　unsafe {
　　return *p;
　}
}

**デフォルトの名無しさん** · 2024/08/25(日) 00:56:39.20

unsafe { p.as_ref().expect("p is not null") }
unsafe { p.as_mut().expect("p is not null") }
unsafe { &*p }
unsafe { &mut *p }

**デフォルトの名無しさん** · 2024/08/25(日) 01:28:05.04

そもそもRustの参照とC++の参照が1対1に対応しないので、そこを無視してもどうなんだという問題

**あぼーん** · NG

あぼーん

**デフォルトの名無しさん** · 2024/08/25(日) 06:34:29.42

>>438
まじか

**デフォルトの名無しさん** · 2024/08/25(日) 15:06:59.24

>>433
std::slice::from_raw_parts
std::slice::from_raw_parts_mut

**デフォルトの名無しさん** · 2024/08/25(日) 16:07:14.33

unsafe大好き

**デフォルトの名無しさん** · 2024/08/26(月) 07:21:14.48

unsafe rustよりzig

**デフォルトの名無しさん** · 2024/08/26(月) 07:32:17.72

zigは未完成

**デフォルトの名無しさん** · 2024/08/26(月) 11:03:43.55

zigよりNim

**デフォルトの名無しさん** · 2024/08/26(月) 12:45:51.89

Rustでunsafeを迂闊に使っていると信用失墜リスクがある
例えば安全に書けるシーンでunsafeを使っていればRustに疎くレベルが低いと客観的に判定されてしまう
そして書いたコードは信頼されなくなるため要注意だ

**デフォルトの名無しさん** · 2024/08/26(月) 13:27:24.67

んでNimよりCってわけ

**デフォルトの名無しさん** · 2024/08/26(月) 23:59:19.70

unsafeなしに拘るならそもそもunsafeという仕様のない言語を使えば良いのでは

**デフォルトの名無しさん** · 2024/08/27(火) 00:09:57.79

unsafeはFFI部分と基盤ライブラリで必須
そのためにある

**デフォルトの名無しさん** · 2024/08/27(火) 01:18:15.13

あんまり必死になると>>307が図星なのがバレるぞ

**あぼーん** · NG

あぼーん

**デフォルトの名無しさん** · 2024/08/27(火) 05:12:31.56

>>450
既に貰ってる