Rust part38

公式
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/
（コミュニティによる日本語翻訳版もあります: https://doc.rust-jp.rs/book-ja/）

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

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

前スレ
Rust part37
https://mevius.5ch.io/test/read.cgi/tech/1784283151/

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

ついに正解に辿り着いたのか

>>58-62
間違いがあるな
ムーブ = ディープコピーだなんて言ってる奴はいない
その人はずっとスタックがpopされる時に移動する値があるという話をしている
なので>>60が言ってることはむしろ>>60自身に当てはまってて、

> Rustはオブジェクトをそのまま値として変数に入れたりムーブできる
> だからオブジェクトの中に参照を持たない限りディープコピーにならない

これには1つ重大な見落としがある
Rustではムーブは所有権を移す行いであるため、メモリの寿命はムーブされた後のスコープによって管理される

しかし、スタックがpopされる場合そのメモリ領域は解放されてしまうため、そのままではムーブしたはずなのにUse-after-freeが発生する
これを防ぐためにはpopされる領域から事前にメモリを書き写す必要があり、これは実体を丸ごと移動させるディープコピーとならざるを得ない
これがずっと言われてることであって、Rustの仕様としては完全に正しい

これについて、前スレではReturn Value Optimizationで防がれるという、いい主張があったがこれはコンパイラの最適化によるものであって、仕様として確定したものはないという話だった

逆に、今>>58-62が言ってるのはヒープ領域に限ったムーブの説明にしかなっていないし、>>56の例はスコープが変わっていないのでスタックのpopは発生しないため例として不適切であることになる
そのため、前スレにおける議論よりもずいぶん低レベルで、とにかく相手が言っていることを間違っていると言えれば満足というものに変わってしまっている

>>63
>>これは実体を丸ごと移動させるディープコピーとならざるを得ない

そこが貴方の間違い
単なる値のムーブなのでディープコピーではない
Rustのムーブがディープコピーになることはない

それな
というか、そうじゃなかったらRVOなんて存在しないんだよな
>>58-62の主張だとRustにはRVOは存在しないことになるが、本当にそうかどうかは調べた方がいい

>>64
また勘違い解釈が出たな

> 単なる値のムーブなのでディープコピーではない
それたぶんこのスレに入ってからも何回か否定されてるぞ

>>65
たぶん>>63に同意してるんだと思うが、まあそりゃそうなるんだよな
スタックがpopされるときに実体のコピーが発生しないと仮定すると、RVOという言葉はおかしくなる
それは最適化じゃなくて言語仕様としての義務になるからな

>>64
ディープコピー（深いコピー）とは - IT用語辞典 e-Words
https://e-words.jp/w/%E3%83%87%E3%82%A3%E3%83%BC%E3%83%97%E3%82%B3%E3%83%94%E3%83%BC.html

> ディープコピーとは、配列やオブジェクトなどのデータ構造を複製する際、同じ構造の実体を新たに作成して対応するデータを写し取る方式。


Deep copy (ディープコピー) - 用語集 | MDN
https://developer.mozilla.org/ja/docs/Glossary/Deep_copy

> オブジェクトの ディープコピー とは、コピー先のオブジェクトのプロパティがコピー元のオブジェクトのプロパティと同一の参照（同じ値を指す）で共有しないコピー方法のことです。結果として、コピー元かコピー先のどちらかを変更しても、もう一方オブジェクトにも変更を及ぼしていないことを保証できます。すなわち、コピー元かコピー先に意図せずに予期しない変更が加えられるこはありません。この振る舞いはシャローコピーとは対照的です。シャローコピーでは、コピー元かコピー先のどちらかを変更するともう一方のオブジェクトも変更される可能性があります。

> プロパティがすべてプリミティブ値であるオブジェクトのコピーは、ディープコピーとシャローコピーの両方の定義に当てはまります。しかし、このようなコピーの深さについて話すのはやや無意味です。というのも、このコピーには入れ子プロパティがなく、ディープコピーについては通常、入れ子プロパティを変更するコンテキストで話すからです。

>>65
RVOはシャローコピーだぞ
例えばVecを返す時に連続体の部分はコピーしない
長さ二つとアドレスの3点のみコピーする

>>63が言ってることと同じことが書いてあるな
https://users.rust-lang.org/t/does-rust-have-return-value-optimization/10389

> it's just like (current) C++ in this regard - it's an optimization, without any guarantees that it'll happen. Not sure if that will change with MIR maturing and rust doing its own pre-LLVM optimizations.
→ これは(現在の)C++とまったく同じで、それが実現するという保証がまったくない最適化です。MIRが成熟し、Rustが独自のLLVM前最適化を行うことで、それが変わるかどうかはわかりません。

>>69
何言ってんだこいつ
RVOが最適化として存在するということは、大前提それで最適化されないとディープコピーされることを意味している、という話だぞ

>>70
それはディープコピーとシャローコピーの違いと一切の関係がない

>>71
貴方はRVOが何なのか理解できてないのか？
関数が値をレジスタ返しできない時に呼び出し元に直接書き込む最適化の話だぞ
どこにもディープコピーの要素がない

>>72
当たり前だろ
そんな低レベルな話はMDN見ろで済むこと

>>74
MDNにディープコピーの説明がある
Rustのムーブがディープコピーになることはない

>>73
まだRVOがディープコピーしてると思ってるの日本語読解力が0どころかマイナスだろ
ディープコピーを防ぐための機能がRVOじゃマヌケ

値をレジスタ返しできないなんてことは関係ない
そもそもレジスタで返されたところでメモリに書き込む必要はあるんだから、レジスタで返せたらすっきり終わりだと思ってる時点で頭が回っていない
というかこの複おじの「レジスタを魔法のストレージだと思っている」現象何なんだ

>>75
はいはい、お前の中ではそうなんだねｗ
どう見ても>>63は完全に正しいことを言ってるけど、複オジにはわからないか

>>73
複オジは知らないことで威張るの好きだよな
RVOはオブジェクトのコピーを省略するための最適化じゃマヌケ

Rustではムーブは所有権を移す行いであるため、メモリの寿命はムーブされた後のスコープによって管理される

しかし、スタックがpopされる場合そのメモリ領域は解放されてしまうため、そのままではムーブしたはずなのにUse-after-freeが発生する
これを防ぐためにはpopされる領域から事前にメモリを書き写す必要があり、これは実体を丸ごと移動させるディープコピーとならざるを得ない
これがずっと言われてることであって、Rustの仕様としては完全に正しい

これについて、前スレではReturn Value Optimizationで防がれるという、いい主張があったがこれはコンパイラの最適化によるものであって、仕様として確定したものはない

> it's just like (current) C++ in this regard - it's an optimization, without any guarantees that it'll happen. Not sure if that will change with MIR maturing and rust doing its own pre-LLVM optimizations.
→ これは(現在の)C++とまったく同じで、それが実現するという保証がまったくない最適化です。MIRが成熟し、Rustが独自のLLVM前最適化を行うことで、それが変わるかどうかはわかりません。
https://users.rust-lang.org/t/does-rust-have-return-value-optimization/10389

The Bookには「there’s a design choices … : Rust will never automatically create “deep” copies of your data」と書いてる

Rustは自動的にディープコピーを作ることは決してない、という設計選択をしている

The Bookの著者が勘違いをしているのか君が勘違いをしているのかどっちだろうね〜？

>>80
そりゃThe Bookにおいてはディープコピーという言葉はヒープのみに限定して使われてるからな
一般的な用法ではないが、そのように定義しているというだけの話

そこは最適化の有無と関係ない
ムーブは最適化されても最適化されなくてもシャローコピー

>>82
そうだとすれば、スタックに置かれたデータはRVOがないとムーブで戻り値として返却できないことになるな
あるかないかわからない最適化がないと返却できない、そんな言語仕様だと君は言いたいのかい？

>>81
ヒープに限定されない
参照先がスタック上でも同じ
ムーブは参照先をコピーしない

>>83
ムーブは最適化の有無に関係なくシャローコピー
ディープコピーしない

>>84
じゃあどうやってスタック上の値が戻り値としてムーブされるのか説明してもらってもいい？
スタックだから当然関数の終わりでスコープが終わることで、このメモリ領域はpopされるぜ？

>>83
ムーブは最適化がなければビットコピーだよ
RVOを切っても同じ

>>81
ヒープのみに限定して使われてるってThe Bookのどこに書いてあるのかな〜？
おしえておしえて〜

Rustではムーブは所有権を移す行いであるため、メモリの寿命はムーブされた後のスコープによって管理される

しかし、スタックがpopされる場合そのメモリ領域は解放されてしまうため、そのままではムーブしたはずなのにUse-after-freeが発生する
これを防ぐためにはpopされる領域から事前にメモリを書き写す必要があり、これは実体を丸ごと移動させるディープコピー（※）とならざるを得ない
これがずっと言われてることであって、Rustの仕様としては完全に正しい

これについて、前スレではReturn Value Optimizationで防がれるという、いい主張があったがこれはコンパイラの最適化によるものであって、仕様として確定したものはない

> it's just like (current) C++ in this regard - it's an optimization, without any guarantees that it'll happen. Not sure if that will change with MIR maturing and rust doing its own pre-LLVM optimizations.
→ これは(現在の)C++とまったく同じで、それが実現するという保証がまったくない最適化です。MIRが成熟し、Rustが独自のLLVM前最適化を行うことで、それが変わるかどうかはわかりません。
https://users.rust-lang.org/t/does-rust-have-return-value-optimization/10389

※MDNの定義であり、一般的
The Bookではビットコピーという変わった言葉が使われることがあるらしい、複オジ情報だから怪しいが

>>86
ムーブが何かを正しく覚えよう
trait Copyのところに書かれてるよ
最適化されないとコピーされる
もちろんディープじゃない

>>84-85
>>87-88
こいつら>>86の

>>じゃあどうやってスタック上の値が戻り値としてムーブされるのか説明してもらってもいい？
>>スタックだから当然関数の終わりでスコープが終わることで、このメモリ領域はpopされるぜ？

には答えられなさそうだな

>>90
お前の中ではディープじゃないのはわかったって
MDN定義ではディープ、お前定義では違うってのはわかったから、そこはもういいから質問に答えようぜ

>>89
君だけディープコピーを勘違いしてる

>>93
原文出されて否定されてるのに、まだそれ言ってるの流石に飽きたからもういいよ

>>92
なるほど
MDNの定義を誤読してるのか
まずはちゃんと読め

Rustではムーブは所有権を移す行いであるため、メモリの寿命はムーブされた後のスコープによって管理される

しかし、スタックがpopされる場合そのメモリ領域は解放されてしまうため、そのままではムーブしたはずなのにUse-after-freeが発生する
これを防ぐためにはpopされる領域から事前にメモリを書き写す必要があり、これは実体を丸ごと移動させる実体ごとのコピー（※）とならざるを得ない
これがずっと言われてることであって、Rustの仕様としては完全に正しい

これについて、前スレではReturn Value Optimizationで防がれるという、いい主張があったがこれはコンパイラの最適化によるものであって、仕様として確定したものはない

> it's just like (current) C++ in this regard - it's an optimization, without any guarantees that it'll happen. Not sure if that will change with MIR maturing and rust doing its own pre-LLVM optimizations.
→ これは(現在の)C++とまったく同じで、それが実現するという保証がまったくない最適化です。MIRが成熟し、Rustが独自のLLVM前最適化を行うことで、それが変わるかどうかはわかりません。
https://users.rust-lang.org/t/does-rust-have-return-value-optimization/10389

※複オジ定義でディープコピーじゃないということで延々そこにばかり嚙みついて議論を回避しようとするので、複オジ定義の言葉に書き換えてあげました

>>95
お前がなーｗ


Deep copy (ディープコピー) - 用語集 | MDN
https://developer.mozilla.org/ja/docs/Glossary/Deep_copy

> オブジェクトの ディープコピー とは、コピー先のオブジェクトのプロパティがコピー元のオブジェクトのプロパティと同一の参照（同じ値を指す）で共有しないコピー方法のことです。結果として、コピー元かコピー先のどちらかを変更しても、もう一方オブジェクトにも変更を及ぼしていないことを保証できます。すなわち、コピー元かコピー先に意図せずに予期しない変更が加えられるこはありません。この振る舞いはシャローコピーとは対照的です。シャローコピーでは、コピー元かコピー先のどちらかを変更するともう一方のオブジェクトも変更される可能性があります。

> プロパティがすべてプリミティブ値であるオブジェクトのコピーは、ディープコピーとシャローコピーの両方の定義に当てはまります。しかし、このようなコピーの深さについて話すのはやや無意味です。というのも、このコピーには入れ子プロパティがなく、ディープコピーについては通常、入れ子プロパティを変更するコンテキストで話すからです。


どう見ても実体のコピーはディープコピーだぞｗ

>>95
反論されないようにあえて何がディープコピーになるのか言わないようになってて草

>>93
>>95
やっぱりこいつら>>86の

>>じゃあどうやってスタック上の値が戻り値としてムーブされるのか説明してもらってもいい？
>>スタックだから当然関数の終わりでスコープが終わることで、このメモリ領域はpopされるぜ？

には答えられないみたいだな

>>96で複オジ定義準拠になったからこれで本題に入れるなｗ

なぜかMDNのJavaScriptのオブジェクトについてのディープコピーの話を見てるから誤解してるんだろうな
まず重要なことはJavaScriptのオブジェクトは値そのまま変数などへ格納することができない
オブジェクトの値を指す参照が変数はプロパティに格納される
だから深さが一つ異なる

>>97
キミの勘違いがこれで理解できただろう

>>101
顔真っ赤で草
まともな文章も書けなくなってるじゃんｗ

>>99
ムーブはRust公式に書かれてるように最適化がなければ単なるビットコピー
つまりディープコピーではなくシャローコピーになる

>>101-102
別にそのページJavaScriptのページじゃねえぞ
確認してみればわかることだが

>>104
シャローコピーの定義が壊れてますよｗ

>>101-102
>>104
やっぱりこいつら>>86の

>>じゃあどうやってスタック上の値が戻り値としてムーブされるのか説明してもらってもいい？
>>スタックだから当然関数の終わりでスコープが終わることで、このメモリ領域はpopされるぜ？

には答えられないみたいだな

Rustではムーブは所有権を移す行いであるため、メモリの寿命はムーブされた後のスコープによって管理される

しかし、スタックがpopされる場合そのメモリ領域は解放されてしまうため、そのままではムーブしたはずなのにUse-after-freeが発生する
これを防ぐためにはpopされる領域から事前にメモリを書き写す必要があり、これは実体を丸ごとメモリ上で移動させる、全体のコピー（※）とならざるを得ない
これがずっと言われてることであって、Rustの仕様としては完全に正しい

これについて、前スレではReturn Value Optimizationで防がれるという、いい主張があったがこれはコンパイラの最適化によるものであって、仕様として確定したものはない

> it's just like (current) C++ in this regard - it's an optimization, without any guarantees that it'll happen. Not sure if that will change with MIR maturing and rust doing its own pre-LLVM optimizations.
→ これは(現在の)C++とまったく同じで、それが実現するという保証がまったくない最適化です。MIRが成熟し、Rustが独自のLLVM前最適化を行うことで、それが変わるかどうかはわかりません。
https://users.rust-lang.org/t/does-rust-have-return-value-optimization/10389

※複オジ定義でディープコピーじゃないということで延々そこにばかり嚙みついて議論を回避しようとするので、複オジ定義の言葉に書き換えてあげました
※複オジ定義のビットコピー？　しかし最初はプリミティブ値のことだと言っていたので怪しめ

>>107
そりゃそうよ
複おじは「スタックに巨大データを置いても欠点はない、ムーブすれば実体がコピーされることはない」と言い続けてきた手前、それに答えたらどうやっても自滅するしかない

>>105
MDN確認したがJavaScriptの話しか書かれていない

https://developer.mozilla.org/en-US/docs/Glossary/Deep_copy
Two objects o1 and o2 are structurally equivalent if their observed behaviors are the same. These behaviors include:

1. The properties of o1 and o2 have the same names in the same order.
2. The values of their properties are structurally equivalent.
3. Their prototype chains are structurally equivalent (although when we deal with structural equivalence, these objects are usually plain objects, meaning they both inherit from Object.prototype).

>>110
お前が勝手にそう思ったって感想文はいいからｗ
そのページの中にJavaScriptのことだという記載がどこにもないし、その親の
https://developer.mozilla.org/en-US/docs/Glossary/
にもそんなことは一言も書かれていない
全部複おじの妄想

>>107-108が話題を本題に移したから、複おじは雑な定義論争で引っ掻き回せる古い話を続けたくて仕方がない

>>111
Object.prototypeなど全てJavaScriptだけに出てくる用語だぞ
そこはJavaScriptのためのページだ

>>110
>>113
やっぱりこいつら>>86の

>>じゃあどうやってスタック上の値が戻り値としてムーブされるのか説明してもらってもいい？
>>スタックだから当然関数の終わりでスコープが終わることで、このメモリ領域はpopされるぜ？

には答えられないみたいだな

Rustではムーブは所有権を移す行いであるため、メモリの寿命はムーブされた後のスコープによって管理される

しかし、スタックがpopされる場合そのメモリ領域は解放されてしまうため、そのままではムーブしたはずなのにUse-after-freeが発生する
これを防ぐためにはpopされる領域から事前にメモリを書き写す必要があり、これは実体を丸ごとメモリ上で移動させる、全体のコピーとならざるを得ない
これがずっと言われてることであって、Rustの仕様としては完全に正しい

これについて、前スレではReturn Value Optimizationで防がれるという、いい主張があったがこれはコンパイラの最適化によるものであって、仕様として確定したものはない

> it's just like (current) C++ in this regard - it's an optimization, without any guarantees that it'll happen. Not sure if that will change with MIR maturing and rust doing its own pre-LLVM optimizations.
→ これは(現在の)C++とまったく同じで、それが実現するという保証がまったくない最適化です。MIRが成熟し、Rustが独自のLLVM前最適化を行うことで、それが変わるかどうかはわかりません。
https://users.rust-lang.org/t/does-rust-have-return-value-optimization/10389

コピーされることはないって言い続けてた複おじさん、急に黙ったけど反論マダー？

>>107
ムーブとは最適化が行われない限り単なるビットコピーのこと、という基本は理解できてる？
あとシャローコピーは入れ子構造を追わずに単なるビットコピーというのも理解できてる？

>>115
そのRVOは2度のコピーを1度のコピーにする最適化

>>117
答える気がないってことは理解できたぞ
話を逸らすことにだけは熱心だな

>>118
二度のコピーって何だよｗ
コピーは一度、全体をコピーするだけだぞ

複おじは反論が厳しいと気づいたら上げ始めるからわかりやすい

>>114
関数の戻り値は常にムーブ
レジスタで戻すか戻せなければRVO
RVOを禁じても単なるコピー
ディープコピーは絶対に起きない

>>122
複オジは知らないことで威張るの好きだよな
RVOはオブジェクトのコピーを省略するための最適化じゃマヌケ
あと、お前定義のディープコピーはもうどうでもいいから書かなくていいよｗ

>>122
複おじさんはずっと勘違いしてるけど、レジスタはメモリじゃないよ
レジスタで返したところで、直後で捨てるんじゃなかったらメモリに書き込むことは確定だからメモリに書くのは前提
RVOはそのメモリに書き込むことを防ぐ最適化

>>123
同じ意見を言ってるだけじゃないか
同じだから異論はない

戻り値の場合、あらかじめ受け取る側にメモリを用意させておけば、そのメモリに書き込ませてやると戻り値を返す時にコピーしなくていい

>>125
レジスタで戻すというのが勘違いを含んでる
それも最適化の一部であって、元々はRVOがない時の挙動は単純な全体のコピー

>>124
> RVOはそのメモリに書き込むことを防ぐ最適化

違うよ
RVOはそのメモリに直接書き込む最適化

>>128
スコープ外のメモリには書き込めないので、そこに書き込ませるという最適化をすることで、元々戻り値をコピーしてメモリに書き込まなければならないという問題をスキップしている、という話をしてるんだぞ

>>127
サイズ内ならレジスタで戻すことは各アーキテクチャのABIで決められている
これは守ることは必須
最適化を全くしない設定にしても必ずレジスタで戻す

>>122
メモリに書き込むべきものをレジスタ上で済ませられるなら済ませる、というのはそれはそれで別の最適化なんだよな
元々メモリに書き込む必要がなければRVOが必要ないのはその通りだが、戻り値をレジスタで返すというのはRVOと同様に不自然な挙動であると言える
本来のスタックとスコープの仕様を考えれば、そこはコピーされることになるからね

>>129
それは正しい
RVOはそのメモリに直接書き込む最適化

>>131
それは間違っている
各CPUアーキテクチャのABIによって規定レジスタで返せる時はレジスタ返しが定められている
これは最適化ではない
最適化オプションを無効にしても行なわれる

まだシャベリ場やってたんだ
暑いですね

今日もC++の話で盛り上がっているようですね

Rustも同じだよ
LinuxならSystem V ABI
例えばx86-64なら関数の戻り値は16バイトまでならレジスタ返しraxとrdxで返す
それを超えるとメモリ返し
隠れた第一引数にそのアドレスが渡されて来るのでそこに書き込む
第一引数はレジスタrdiで渡って来る
ここまでは最適化と関係なくABIで決まってる

RVOがないと
一旦ローカル変数用のメモリに書き込んで戻り値を生成
その後に先ほどのrdiが示す場所へコピー

RVOがあると
いきなりrdiが示す場所で戻り値を生成

いずれの場合でもディープコピーは起きない

GPTでRust関連ニュースを予約しとけば良さそう🤔

初代複オジは過去の自分の生き写しかのような二代目複オジを見ていまどういう気持ちなんだろう

クソどうでもいいガイジ😂
関わってる奴らもガイジ😂

Rustの話ができないくせに煽り書き込みには熱心な奴が一番のガイジ

>>136
複オジ定義の、と付けとかないと初心者さんが混乱するだろｗ

>>135
どこにC++の話があるんだよｗ
Rust使ったことないんだろうなｗｗ

Rustは使ってみたいのですが、使い道がないのです
ここを見れば、Rustでなければ作れない素晴らしいソフトウェアや、生産性の劇的な向上の話があると思いました
どうやら、そんなものはないようですね

>>142
そりゃそうだろ
Rustは優秀だけどただのプログラミング言語
どう使うかはプログラマが考えること

まあ、まずはThe Book開きなよ
いくつか実例やってる間に思いつくかもよ

初心者は軽量なコマンドラインツール作ってみるのが良いと思う
muslとか使えばシングルバイナリで配布できるし

まさにThe Bookに簡易grepがある

初心者はThe bookを10周しなさい

使い道がないものに投資するのはムリというものです
娯楽なら、Rustより圏論の方が楽しそうな気がしています

ほのかに漂う障害者臭

AIに聞けばここ1週間の議論は1分で終わる
業務効率化しろよお前ら

まとめ
1. Rustのムーブはディープコピーを行わず、所有権だけを移動する。
2. Copyトレイトを持つ型はムーブ時に値がコピーされるが、これは浅いコピー。
3. 明示的にディープコピーが必要な場合は .clone() を使う。
この設計により、Rustはパフォーマンスと安全性のバランスを保ちつつ、ヒープデータの不必要なコピーを避けます。

このスレ、何割が生成AIの書き込み？

ディープコピーが何かを誤解してるアホが一匹
ムーブでディープコピーが起きると暴れてた

前スレの9割がRustアンチ障害者の書き込み

なんかポインタ(Cの)のことをわかっていないもしくは分かる必要がないと思ってる人が多数まじって議論が続いているような気がするのは気のせいか？

AIに聞けばわかることをレスバしてる
精神障害者の自作自演

道具だからねぇプログラミング言語なんて

ハサミだろうがカッターだろうが紙を切ることは出来る

安全装置が付いた栽断機をRustとして
Rustなら安全にまっすぐ切れるよって道具であり
別にカッターナイフと定規でもまっすぐ切れるから出来ることは変わらん

excel開きながら電卓叩く奴も世の中多いように
好きな道具で好きにやればいい

安全装置がついた裁断機は
安全装置を正しく使っている限り
安全装置がついていない裁断機よりは安全

ただし安全装置によって防げる事故というのは
裁断機の利用によって発生しうる事故の一部分でしかなく
裁断作業に危険が伴うことは避けられない

至極当たり前のことだが
これを理解していないRust開発者がなんと多いことか

そこから得られる結論は
安全装置がないものを使う人は愚か
Rustを使おう

safe and unsafe

unsafeは意図的に安全センサーとかを覆い隠したりして
無理矢理動作させる事だね

どうしてもそうしないと出来ないから仕方がなく
だけど、その分危険だから使用者は細心の注意を払うようだと


カーナビの移動時の操作制限を解除してるのとかも
安全のための装置を外すなら使用者がその分安全に注意を払うようなんだよね

unsafeは使われない
unsafeを使う場合は稟議書を通したりもしくは全員の合意を取ったりするなどいずれにせよ皆の監視対象になる