Rust part23
■ このスレッドは過去ログ倉庫に格納されています
今回の件でRustの安全性が確実になったのが興味深いよな >>350 でunsafe利用だった >>371 >>374 誰にでもunsafeが使えてしまうのが問題なのでは？ Rust の制限は機械的に検証可能な範囲に絞ったらそうなったということであって、その制限の範囲内で十分にプログラムが書けるというものでもない。 >>375 >>350 の引数のindexをその型に変えたところでsafeにしたらダメだよ なるほど、欲しい機能を実装していったら、結構安全になったって感じなのかな。OpenBSDみたいな偏執なのとは違う感じか？ indexの境界チェックが律速になるようなコード書いてみてえな >>376 型宣言の時に type My_Int is range -1 .. 5; 範囲宣言(マイナスでも、１からでもＯＫ)できて、範囲を越えたらエラー 配列もその範囲指定で自由に作成できる。 >>383 >>384 >>384 何十年も前なのですまそ 今回の話は実行時境界チェックを無くす(減らす)実行時コスト削減の話だけど How much does Rust's bounds checking actually cost? https://blog.readyset.io/bounds-checks/ こんなもんjavaの速度低下が境界値チェックによるものじゃないってことで話は終わっとると思ったけどな。 unsafeは可能な限り避けるべきで unsafeは極力避けろというアドバイスばっかりでunsafeを適切に閉じ込める基本的な考え方や実装パターンの啓蒙が不十分なんだよね 「unsafeの閉じ込めにはセンスがいるから、教えてもらわないと出来ないやつはunsafeを使うな」 unsafeはライブラリ作者とかがハード周りアクセスするために使うもので、コーダーが使うものじゃないだろ。 >>393 >>392 >>350 のような基本的なミスを犯すやつが後を絶たない windows-rs とか使うと絶望するよな。もうちょいラップして安全なAPIも提供してほしい。 >>395 >>397 その素晴らしい提案がなぜされていないのか考えよう >>394 unsafe はコンパイラが安全性を「論理的に検証できない」部分であって、理論上の都合で出来た区分だよ。 >>401 >>402 >>403 理想をいえばunsafeなんて無いならサイコーだったんだろうね 生ポインタすなわちCPUによるメモリアクセスはunsafe >>406 そこまでsafeな事にこだわるなら、Haskellに行けばいいのでは…？ >>404 #![forbid(unsafe_code)] unsafeな部分の拡張子を変えるというのが有効とはあんま思えんのだよな >>409 >>411 rustもいろいろ問題を抱えてるんだね >>412 >>413 >>414 >>415 結局いつもの「無知なアンチ vs 無知な信者」の薄っぺらい対立になっちゃうのな まあハスケルなんかもinvalidな変数使うようにっての広めるのには役立ったからrustもそういう位置に落ち着くだろ。 unsafeを使う人はライブラリ作成者がほとんどで、残りはシビアなインフラ作成者 >>419 unsafeって書かないといけないってのは結構デフォ禁止よりの処置だと思うが 必要な各企業、各プロジェクトなどで義務付け https://rust-lang.github.io/api-guidelines/ >>422 forbidもunsafe_codeもrustcのlintの一部だな Rust Foundationによる資格認定試験に合格した者だけにunsafe使用パスワードが発行されるようにするしかないな。 どの開発でも >>420 時間がない時に焦ってunsafe使って書いたコードは長期利用すると大変なことになるので書いてから1時間以内に使って捨てよう >>429 >>430 >>432 雑にunsafe使って早く書けるのはFFIくらいかな >>427 >>426 初心者ぼく「禁止しないといけないようなもんが標準で使えるって結局それ危険な言語なんでは？ そもそも普通に書いててunsafe使いたいなって場面がない >>436 rustもプログラマがザコだと使いこなせない言語なんだろ？ たしかにプログラムの品質がいいから出世するって見たことないわ unsafeは面倒 初心者や一般的な人は、unsafeの使い所がないなら、unsafeを使うようなすごい人でもミスをしたり理解不足だったりするって事だから、すごい人が精進すれば解決でしょ。 >>440 >>442 >>448 >>448 unsafeでサクッと終わらせてどんどん仕事取ろうぜ アンチはunsafeを使うと早く書けると誤解しているのが面白い 「借用エラー出たらとりあえずunsafeと書いとけば回避できる」くらいのイメージなんかね このスレの優秀な人たちを安月給で揃えたチーム作れたらunsafeについて真面目に取り組んでもいいんだが 正常なコミュニケーション力を持った優秀なエンジニア ｶﾁｮｰ「では進捗を報告してください」 >>457 >>459 >>458 unsafe使う機会ってほぼないよな 優秀なエンジニアは担当している仕事がいつ頃終わるか明確に答えられる人 システムプログラミング用途も売りにしてなかった？ unsafe使うと変更する時にだるくなるからできるだけ使わない 使う必要があるからunsafeってもんがあるんであって コーダーの「使う使わない」の問題じゃなくて、管理者の「許可する禁止する」の問題なんだよ。 >>451 >>468 ■ このスレッドは過去ログ倉庫に格納されています
