Rust part8

**デフォルトの名無しさん** · 2020/01/24(金) 11:47:52.41

Mozilla発のRust言語のスレ

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

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

前スレ
Rust Part7
http://mevius.5ch.net/test/read.cgi/tech/1563114707/

**デフォルトの名無しさん** · 2020/03/19(木) 15:19:47.59

assert!(!false);
の方が紛らわしくないか？
assert_not!は関数名の方に!あるから見間違えないしスッキリするし直感的な気がする
それにneが内部的に反転してるだけならnotあったほうがいいな

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

usize同士の差の絶対値を求めるのがすごくだるいんですけどなんかいい方法ないすか

**デフォルトの名無しさん** · 2020/03/20(金) 07:38:59.81

if x > y { x - y } else { y - x }
じゃ駄目かい

**デフォルトの名無しさん** · 2020/03/20(金) 08:14:22.57

やっぱそうするしか？

**デフォルトの名無しさん** · 2020/03/20(金) 16:54:06.07

そういう関数を作っておけばええやん。

**デフォルトの名無しさん** · 2020/03/21(土) 19:08:12.84

let mut v = vec![1,2];
std::mem::swap(v[1], v[0]);
assert!(v == vec![2,1]);
こうしたいんですけど、どうすればいいですか？

**デフォルトの名無しさん** · 2020/03/21(土) 19:19:05.58

Vec::swap使え->
Vec::swapは中でunsafe使ってるじゃないですか結局unsafe使わなきゃろくなこと出来ないんですねRustってクソですね

ってやりたい荒らしだろ？
氏ねばいいと思うよ

**デフォルトの名無しさん** · 2020/03/21(土) 19:32:13.45

標準ライブラリ内でunsafe使うのと
自前でunsafe使わされるのとは雲泥の差があると思うんだがｗ

**デフォルトの名無しさん** · 2020/03/21(土) 20:27:19.94

ヤクザかな？

**デフォルトの名無しさん** · 2020/03/21(土) 20:38:04.64

ほら、万が一の荒らしじゃないケース用に答えも同時に提示してあげたのにそっちには見向きもしないでしょ
そりゃそうだよね、実際はやりたいことの質問じゃなくてRustをディスるための質問なんだもんね

つかそもそも本当に質問のことがやりたいなら提示したコードをコンパイルしようとしてるはずだよね
そしたら親切なコンパイラが&mutで借用しろって教えてくれてるよね
そしたらそれに従ったら今度は親切なコンパイラが同時に2つmutな借用は作れないって教えてくれてるよね
じゃあどうしたら良いですか？ってなるのが普通だよね

それがないってことは質問を装っていながらコンパイルすらしてないってことだからね
荒らすんなら荒らすでもうちょっと頭使おうね☆

**デフォルトの名無しさん** · 2020/03/22(日) 13:10:01.70

Rustにも、次のような「言語定義された smart pointer」があり、
~ : 一回だけ(unique) 参照する smart pointer。
@ : 複数回参照できる smart pointerで、GC を使っている。
drop なるものが、C/C++ の free()やdeleteの機能を持つ。
という認識で正しいのでしょうか。

**デフォルトの名無しさん** · 2020/03/22(日) 14:01:25.52

>>202
参照カウンタを1引くようなDeref や、C/C++の単項演算子の方の「*」と
全く同様な「参照はずし演算子」の「*」もあるようですね。
また、~ や @ よりは少し高レベルになった smart pointer として、
Box<T> が、参照カウンタ方式の smart pointer として Rc<T> が、
さらに、動的(?)になった smart pointer としてRef<T>やRefMut<T>
があるようです。
凄く複雑です。

**デフォルトの名無しさん** · 2020/03/22(日) 14:28:20.92

参照型の変数 r への代入は、普段は、
r = 1;
などでよいようですが、なぜか、*r と書かなければなら無い事があるようです。
また、&i32の変数rとi32の変数aを比較する場合比較する場合、
前者には *r を付けないといけないようです。
難しいです。

**デフォルトの名無しさん** · 2020/03/22(日) 15:43:22.86

6年以上前に削除された仕様の良し悪しを語りたいのか？

**デフォルトの名無しさん** · 2020/03/22(日) 15:57:03.70

rustの未来教えて

**デフォルトの名無しさん** · 2020/03/22(日) 16:08:02.82

>>205
詳しくお願いします。

**デフォルトの名無しさん** · 2020/03/22(日) 16:50:19.83

>>207 いやbook読んでよ。もし@とか~についての記述があったら逆に教えて欲しいくらいだ

**デフォルトの名無しさん** · 2020/03/22(日) 17:28:44.77

>>204
&と*は常に逆の関係にあるようです。
The opposite of referencing by using & is dereferencing, which is accomplished with the dereference operator, *.

vがvecへの参照型の場合でも
v.push(5);
と書けてしまうのは、実体vとポインタ pV に対して
v.push(5);
pV->push(5);
と区別していたC++と違っているために個人的に混乱していただけのようです。

もう一つは、参照ではなく、
let a = 5;
let a = a + 1;
のように shadowing を行う例が個人的に混乱の原因になっていたようです。

参照型 &T の場合には、
let r : &mut TYPE = &a;
のようにした後は、
*r = xxx;
のように、原則的に * を付けて参照を一段階戻す必要があるようです。
*をつけなくていいのは、メンバ関数呼び出しの、
r.func();
のような例の場合だけで、もしかすると、
(*r).func();
としてもコンパイルが通るかもしれません。

**デフォルトの名無しさん** · 2020/03/22(日) 17:30:53.65

>>208
https://pcwalton.github.io/2013/03/18/an-overview-of-memory-management-in-rust.html
Rust の 2種のスマートポインター、^ と @ に詳しいです。

「book」と言えば、詳しく学ぶには、まさに
https://doc.rust-lang.org/book/index.html
が初心者には分かり易いようです。
この本のことでしょうか？

**デフォルトの名無しさん** · 2020/03/22(日) 17:52:06.65

7年も前の情報を無条件に信じられるピュアさが俺にも欲しいよ

**デフォルトの名無しさん** · 2020/03/22(日) 17:52:35.28

>>210
Rustの1.0リリースは2015年なので
それより古い資料は「昔そういう検討がなされたことがある」程度の意味しかない。
この5年の間に変わった仕様も結構あるし。

**デフォルトの名無しさん** · 2020/03/22(日) 18:32:23.24

初心者なんだけど
もし１つの変数（所有権）にマルチスレッドで書き込みをしようと思ったら、
Rustの借用のルールだと不可能ですか？
複数のイミュータブルな参照を作る事になりますが、できないんですよね？

**デフォルトの名無しさん** · 2020/03/22(日) 18:40:28.26

あまちがえました
訂正：
複数のミュータブルな参照を作る事になります

**デフォルトの名無しさん** · 2020/03/22(日) 18:53:15.15

>>213
同時じゃなければ可能なので
他のマルチスレッドプログラミングと同じく排他制御をすればいい

**デフォルトの名無しさん** · 2020/03/22(日) 19:02:35.81

実行時にデータ競合系の問題が生じない代わりに
コーディング時に借用チェッカーとの戦いをするという感じになるんですかね

**デフォルトの名無しさん** · 2020/03/22(日) 19:17:35.15

>>210 そのbookだよ。オフィシャルのドキュメントを読まずにどうして深入りできようか
１点だけ。rustではobj.method()とするとメソッドの引数の型(&とか&mutとか)に合うようにobjに*とか&とか付ける仕様になってる
メソッド呼ぶ時のobjに対してこっちが*とか&とか付ける必要は特に無い

**デフォルトの名無しさん** · 2020/03/23(月) 01:35:58.42

>>217
bookの話、了解しました。
後半、「メソッドの引数の型」とは、た第一引数 thisのことでしょうか。

**デフォルトの名無しさん** · 2020/03/23(月) 01:39:22.78

所有権、借用、ライフタイムについて勉強してみた。
でも他の言語でも排他制御とか非同期処理用クラスで非同期処理に対応できるわけで、
結局どれくらい御利益があるのか分からなかった。

**デフォルトの名無しさん** · 2020/03/23(月) 02:29:29.77

Rustの変数束縛、所有権、借用などで自動化されるのは、
「スタック変数」のポインタが、ブロックの外や関数の外に不用意に出ない
事だけで、Heapから確保されたオブジェクトの自動解放は、
参照カウンタや Garbage Collection を用いずに静的解析のみで行うことは出来ない、
という認識で正しいのでしょうか？？

**デフォルトの名無しさん** · 2020/03/23(月) 02:39:09.37

>>220
例えば、Cだと、
int *func()
{
　int a;
　return &a;
}
としても警告は出る可能性はあってもコンパイルエラーにはなりませんが、
Rustでは同等のことはできないようになっていますね。
でも、Heapから確保したオブジェクトは、それを参照している変数の個数は
動的に変わります。というのは、Heapとは解放のタイミングを後に遅らせる
ための仕組みな分けですから。
オブジェクトを参照している変数の個数は静的に決まらないと言うことは、
参照カウンタやGarbageCollectionのような動的な検査の仕組みが全く無ければ
解放できないはずですね。

もし静的に解放タイミングを決められる可能性があるとすれば、参照の個数に上限を
設けることによってです。簡単な例ではそのオブジェクトを参照する変数が1つしか
ないなら、その変数にnullや別の値が代入されたり、その変数が削除されるタイミング
だけを静的に調べれば自動解放できるはずです。
しかし、2つ以上になった場合、参照カウンタ無しで静的に削除タイミングを決定するのは
かなり難しくなります。

**デフォルトの名無しさん** · 2020/03/23(月) 03:10:34.91

私が読んだ説明記事では所有権やライフタイムはローカル変数かつシングルスレッドの例しかなかったんですが、
それだとRustがどう非同期処理に強いのかイメージできませんでした。
グローバル変数やマルチスレッドでライフタイム等の概念が活用されている例ないですか？

**デフォルトの名無しさん** · 2020/03/23(月) 06:41:08.54

Rust では所有権が移るから、資源を共有しないからだろ

資源を共有すると、アクセスするタイミングで、バグってしまう。
A を更新 → B を更新 → Aを読み取り

間に、Bが入ったことで、AはBの値を読み取ってしまったけど、
その場ではエラーにならず、かなり後になって、データが何かおかしいと誰かが気づくかも知れない。
気づかないかも知れない

だから、あちこちで排他制御をせざるを得ない。
そうすると、デッドロック・タイムアウトも考えないといけない

**デフォルトの名無しさん** · 2020/03/23(月) 09:52:06.45

資源を共有しないんじゃなくて、共有していい資源かどうかを型（SendとSync）で区別している。
なので排他制御が必要な箇所に入ってなかったらコンパイルエラーにできる。
だからデッドロックなんかは起きるけど、レーシングは起きないって感じ。
ライフタイムはそれほど関係ない。

**デフォルトの名無しさん** · 2020/03/23(月) 12:20:19.11

マルチスレッドの話は置いておいて、そもそも Rustでは、Heapから確保したオブジェクトの解放は自動化されてますか？

**223** · 2020/03/23(月) 12:54:01.89

>>223
修正

>A を更新 → B を更新 → Aを読み取り
スレッドA が共有資源を更新 → B が更新 → Aが読み取り

**デフォルトの名無しさん** · 2020/03/23(月) 13:43:29.57

基本的なことが理解出来てない人はまずThe Bookを読もう

次からテンプレに書いといたほうが良さそう

**デフォルトの名無しさん** · 2020/03/23(月) 15:20:59.29

読んでそこまでたどりつくのは大変過ぎますので、どなたか分かる方が >>225 に答えていただければ幸いです。

**デフォルトの名無しさん** · 2020/03/23(月) 15:33:10.24

>>225
自動で解放される。なぜされるのかが気になるならいろいろ想像してないでthe bookを読んだ方がいいと思う。

**デフォルトの名無しさん** · 2020/03/23(月) 15:33:45.55

贅沢は敵です。

**デフォルトの名無しさん** · 2020/03/23(月) 15:38:31.12

Rc<T> は参照カウンタ方式で自動解放されますが、循環参照があった場合には自動解放されず、メモリーリークするそうです。
つまり、RustはHeapのメモリーを完全自動では解放できないのです。
C#やJavaは遅いですが、循環参照がある場合でも、GarbageCollectionにより完全自動で解放されます。

**デフォルトの名無しさん** · 2020/03/23(月) 15:39:33.51

つまり、「Rustは、GarbageCollectionがなくてもメモリ解放が自動化されている」
というのは嘘です。

**デフォルトの名無しさん** · 2020/03/23(月) 15:40:41.93

>>228
その部分だけの説明は出来ない。そこにたどり着くまでの説明は関連してるから。
体系立てて説明している文書が公式にあるのにそれより上手い説明が出来るわけないだろ。

**デフォルトの名無しさん** · 2020/03/23(月) 15:41:06.82

>>231
https://stackoverflow.com/questions/55553048/is-it-possible-to-cause-a-memory-leak-in-rust

[Q] Is it possible to cause a memory leak in Rust?

Is there any way of causing a memory leak in Rust? I know that even in garbage-collected
languages like JavaScript there are edge-cases where memory will be leaked, are
there any such cases in Rust?

[A1]

Yes, leaking memory in Rust is as easy as calling the std::mem::forget function.

You can also leak memory if you create a cycle of shared references:

A cycle between Rc pointers will never be deallocated. For this reason, Weak is used to break cycles.
For example, a tree could have strong Rc pointers from parent nodes to children, and Weak pointers
from children back to their parents.

**デフォルトの名無しさん** · 2020/03/23(月) 15:45:50.08

>>233
結論的に言えば、Heapから確保されたオブジェクトのメモリの解放は自動化されてません。

**デフォルトの名無しさん** · 2020/03/23(月) 15:49:21.93

なんだ。真面目に聞いてるのかと思ったのに。
まぁご自由にどうぞ。

**デフォルトの名無しさん** · 2020/03/23(月) 16:15:56.91

>>236
実際に自動化されていませんよね。

**デフォルトの名無しさん** · 2020/03/23(月) 16:28:50.38

真面目に回答した相手が荒らしだった時って｢何だよ荒らしかよ｣みたいな反応より｢クッソ抜けるwww｣からの｢すいません誤爆しました｣みたいなレスで｢真面目に回答したわけじゃないぞ、シコりながら適当に回答したんだぞ｣的な雰囲気を出してったほうが良さそうじゃない？

**デフォルトの名無しさん** · 2020/03/23(月) 16:58:35.58

Rc<T> だけを使って循環リストを作った場合、循環参照が生じます。
その場合、その循環リスト全体が誰からも参照されなくなって、つまり、不要に
なっても「循環参照問題」が起きるために自動解放できないのです。

C#やJavaでは、この循環参照問題を解決することを主目的として、
遅さを犠牲に Garbage Collection を使っています。
これは「動的解析」に分類されます。

一方、Rustの場合は静的解析だけで済まそうとしていますが、結局、循環参照問題のために
完全自動化は出来ず、解放べきメモリが解放されずに残ってしまうという現象がおきえます。
これを防ぐには、人間側が循環リストの最後と最初を結ぶためには、weak pointer を使う
などの注意深いプログラミングをすることで防ぐしかありません。
つまり、人間の注意深さでメモリーリークを防いでいるだけです。

**デフォルトの名無しさん** · 2020/03/23(月) 17:09:05.71

都合の悪いことには誰も答えません。

**デフォルトの名無しさん** · 2020/03/23(月) 17:35:19.10

>>239
リークしない保証が欲しいならそういう言語 (処理系) を使えばいいじゃん。
Rust はリークを確実に排除することを保証しないし、
Rust の定義するメモリ安全にはリークの排除が含まれないことは明言されている。
https://doc.rust-lang.org/book/ch15-06-reference-cycles.html

GC を使えばメモリリークが起きないってわけでもないし、
「どのような保証を与えるか？」の線引きが違うだけで
きちんと学んできちんと使いこなさなきゃなんだって駄目だよ。

**デフォルトの名無しさん** · 2020/03/23(月) 18:36:24.14

>>241
別に駄目とは言ってません。
「静的解析でメモリ管理を自動化した。」
というのは言いすぎだと言うことです。

**デフォルトの名無しさん** · 2020/03/23(月) 18:54:37.87

そりゃ循環参照とかウンコード書けばの話だろ、何か問題有るのか？

**デフォルトの名無しさん** · 2020/03/23(月) 18:56:19.36

Heap=Rcだと勘違いしてんのかな？

**デフォルトの名無しさん** · 2020/03/23(月) 19:00:04.36

荒らしにかまうやつも荒らし

暇なおじいさんが各言語に難癖つけて回ってる
Kotlinの次はRust

**デフォルトの名無しさん** · 2020/03/23(月) 19:15:41.65

おかしな奴に絡まれるからRustはダメ言語

**デフォルトの名無しさん** · 2020/03/23(月) 19:16:56.45

>>242
結局のところライフタイムは人間が書くし、それを元にいくらかのチェックと推論をするだけ。
今まで自動化できてなかった分 (の一部) を新しいやり方で自動化したってだけのことで、
何もかも自動でやってくれるような最強解析能力を持ってるなんて誰も言ってないよ。
ストローマン論法はやめろよな。

もう一度書くけど、 Rust のシステムはメモリリークの排除を目的にしていない。

**デフォルトの名無しさん** · 2020/03/23(月) 20:19:04.31

藁人形クッソ抜ける？

**デフォルトの名無しさん** · 2020/03/23(月) 21:49:49.89

リソースの開放をプログラム内で完璧にやろうとせずに
プロセスの再起動とかの水準で考えてしまえばいいこともあるかもね

**デフォルトの名無しさん** · 2020/03/23(月) 22:15:27.45

メモリ以外のリソース回収に関してはGCよりRust（あるいはC++のスマポ）がはるかに優秀なんだよな。
Rustに慣れると他言語でusingとかするのが面倒になってくるし、ついつい付け忘れて困る。

**デフォルトの名無しさん** · 2020/03/24(火) 00:09:09.52

Kotlinスレでnullポインタの方が良いと
荒らしてたのと同一人物だったのか

**デフォルトの名無しさん** · 2020/03/24(火) 02:50:53.94

体制側と違う意見は大事。
自分の頭で考えない人は、効能書きや権威やネットで書かれたことを鵜呑みにしてしまう。

**デフォルトの名無しさん** · 2020/03/24(火) 10:04:19.30

メモリ以外のリソース回収なんてむしろなくね

**デフォルトの名無しさん** · 2020/03/24(火) 10:37:53.99

いやファイルポインタ、コネクション、スレッドなどいくらでもあるだろ。

**デフォルトの名無しさん** · 2020/03/24(火) 12:20:20.31

>>250
こんな出てきたばかりの言語に慣れてる人なんているかい。

**デフォルトの名無しさん** · 2020/03/24(火) 12:43:11.53

ファイルハンドルくらいならusingでもいいけど、デバイスコンテキストみたいな微妙に寿命が長いのが困る。
Disposeとか呼び忘れても大抵GCが回収してくれてぱっと見動くけど、
時々回収してくれなくて再現性の低いバグになるとか。

**デフォルトの名無しさん** · 2020/03/24(火) 14:22:30.48

Box<T>のソースを見ていたら、Box::new が次のような1行だけのソースで、
box キーワードを調べてみたら、組み込みの Box::new の実装とだけしか
情報がない。つまり、ソースがあるようで実質的には無い：
impl<T> Box<T> {
　pub fn new(x: T) -> Box<T> {
　　box x
　}
}

同様に Vec<T> のソースを見ていたら、RawVec なるものが出ていて、
RawVecのソースもあったがそこで、core::ptr なるものが使ってあり、
そのソースはないようだ。

Cにとってかわるシステム言語と言いながら、本質的には組み込み関数ばかりで
ソースを追っていくことができない。
Cは最初から理解できて、このような闇が存在しないので、高級アセンブラであり、
システム言語であった。
Rustにはその代わりは務まらないのではないか。

**デフォルトの名無しさん** · 2020/03/24(火) 14:31:46.69

ツッコミどころ満載だけど
荒らしの相手したら負け

**デフォルトの名無しさん** · 2020/03/24(火) 14:40:33.66

正しく
怖がる

**デフォルトの名無しさん** · 2020/03/24(火) 14:43:56.87

巨大学術掲示板群 - アルファ・ラボ
ttp://x0000.net

物理学化学生物学数学天文学地理地学
IT 電子工学言語学方言国語など

**デフォルトの名無しさん** · 2020/03/24(火) 14:44:12.30

Rustは概念が整理されてない。
Cは、ポインタという概念さえ理解すれば(そしてそれは、プログラミングに適性が有る人にはそんなに難しいわけではない)、それだけを頼りにあらゆるものが構築できた。
ところが、Rustはいくら学んでも終わりが無いくらい基礎の部分が難しい。
Box<T>が何をやっているかは、自然言語で説明されるばかりで肝心の
コードも擬似コードもなかなか見つからない。

**デフォルトの名無しさん** · 2020/03/24(火) 15:04:27.63

Box<T>のデストラクタである所の Drop trait の drop 関数を調べてみると、
次のようになっており、compilerの埋め込み処理というコメントになっている。
恐らく、Box<T>が削除される際にコンパイラが何らかの処理を入れているが、
ソース中には書いてない。
こんな状態で Cの後釜を名乗ってほしくない。

unsafe impl<#[may_dangle] T: ?Sized> Drop for Box<T> {
　　fn drop(&mut self) {
　　　　// FIXME: Do nothing, drop is currently performed by compiler.
　　}
}

**デフォルトの名無しさん** · 2020/03/24(火) 15:45:47.44

>>257
それは悔しいけどちょっと理解できる
コンパイラーのソースみるとcompiler builtinで見れないやつとかあるし
いや、どこにあんねんと

**デフォルトの名無しさん** · 2020/03/24(火) 16:11:12.01

Option<Box<T>> で、Some(Box::new<xxx>)
とした場合に、どういう状況の時にこのメモリが解放されるのか、
その仕組みも分かりにくい。

**デフォルトの名無しさん** · 2020/03/24(火) 16:46:57.83

>>264
誤: Some(Box::new<xxx>)
正: Some(Box<T>::new(値))

**デフォルトの名無しさん** · 2020/03/24(火) 17:02:53.60

なんぼ間違えんねん落ち着けや

**デフォルトの名無しさん** · 2020/03/24(火) 17:20:04.56

Rustでの代入記号は、i32/f32/bool/str などのprimitive型以外は原則的に copy動作
ではなく、move 動作のようなもので、所有権の移動が発生する。
例外は、Copy traitsが実装されている型の場合で、その場合も copy動作になる。

Option<XXX>は、Copy traitsが実装されているらしく、Optionが他動詞で代入記号
を使うと、copy動作になるらしい。
ただし、これは文書で明確には述べられてないのでよくわからない。
根拠は、Optionのソースは以下のようになっていて、#[derive(Copy, ...)]の部分が、
Copy traitsを自動実装する、という意味になるらしいからだ：

#[derive(Copy, PartialEq, PartialOrd, Eq, Ord, Debug, Hash)]
#[rustc_diagnostic_item = "option_type"]
#[stable(feature = "rust1", since = "1.0.0")]
pub enum Option<T> {
/// No value
#[stable(feature = "rust1", since = "1.0.0")]
None,
/// Some value `T`
#[stable(feature = "rust1", since = "1.0.0")]
Some(#[stable(feature = "rust1", since = "1.0.0")] T),
}

**デフォルトの名無しさん** · 2020/03/24(火) 17:21:21.85

>>267
誤：Optionが他動詞で
正：Option型同士で

**デフォルトの名無しさん** · 2020/03/24(火) 17:31:35.81

>>263
compiler builtinはコンパイラのソースの中にあるよ

コンパイラのソースでcompiler built-inは見たこと無いけど

**デフォルトの名無しさん** · 2020/03/24(火) 18:30:07.73

>>278
ないよ
https://github.com/rust-lang/rust/blob/master/src/libcore/macros/mod.rs#L1196-L1200
https://doc.rust-lang.org/src/core/macros/mod.rs.html#1146-1150

**デフォルトの名無しさん** · 2020/03/24(火) 18:46:17.48

汽車　汽車　チンポ　チンポ
シコシコ　チンポッポ
チンポを出して　シコシコ　チンポッポ

**デフォルトの名無しさん** · 2020/03/24(火) 19:01:03.96

>>278
期待してるぞ

**デフォルトの名無しさん** · 2020/03/24(火) 23:11:28.78

>>278
それコンパイラのソースじゃないよ

**デフォルトの名無しさん** · 2020/03/25(水) 01:18:57.46

Rustは、コンパイラ時エラーに悩まされる反面、実行時エラーに悩まされるのを減らす
などと言われる。
しかし、コンパイル時エラーが出ると言うことは、裏を返せば、書けないアルゴリズムが存在するということだ。
直感的ではない回りくどい書き方が必要となり記述量が多くなる。
他の言語では好きな書き方が出来て、それはどれも正解だが、Rustでは正解が非常に狭くなる。
正解が狭いことがエラーを減らすなどという人がいるが、実際には、Rustは
書けるアルゴリズムが狭い、と言うことなのである。
これは言語設計の問題である。

なお、ここで言っているアルゴリズムは、全体的なものではなく、細かいミクロ的なものである。
通常の言語では、1つの仕事を細かい変数の使い方まで含めれば数万通り以上に書けるだろう。
そして、そのどれもが正解であり、結果が正しくバグも無いのだから、内のどれかが悪い書き方という
ことは特にない。
ところが、Rustでは、その大部分の書き方が出来ないのである。
駄目だから敢えてできなくしているのではなく、Rustが設計上、書けないアルゴリズムがあるということに他ならない。
つまり、Rustは書けるアルゴリズムが、本来コンピュータが書けるアルゴリズムの内の、非常に狭いサブセットに限られてしまうということである。
これは、Rustの大きな欠陥である。

**デフォルトの名無しさん** · 2020/03/25(水) 01:25:39.41

>>274
「駄目な書き方だからエラーにしている」
と言うのは間違いで、正しくは、
「Rustコンパイラの静的解析能力では、書き方を非常に限定しないと
　正しいことを保障できなかったり、自動化できなかったりするため、
　しょうがなく狭い書き方しか出来なくしている」
と言うことに他ならない。
人間には脳内の静的解析で明らかに正しいことが分かる書き方でも、
Rustコンパイラではでは同じことができないため、敢えて
変数束縛、借用、単一参照など、コンパイラでも解析できる程度の
範囲に書き方を限定して無理やり人間のプログラミングの可能性を
狭めているに過ぎない。

**デフォルトの名無しさん** · 2020/03/25(水) 01:26:44.15

コピペじゃなかったのか…ウケるw

**デフォルトの名無しさん** · 2020/03/25(水) 07:56:19.45

みんなドキュメントコメントで日本語も一緒に書くときってどうしてる？
こんな連ねた感じでいいのかな？
/// Returns a Person object
/// Personオブジェクトを返す

**デフォルトの名無しさん** · 2020/03/25(水) 08:01:15.06

例が悪いわ。
そんな糞コメント書くな、になってしまう。

**デフォルトの名無しさん** · 2020/03/25(水) 08:57:55.31

>>278
期待を裏切りよって

**デフォルトの名無しさん** · 2020/03/25(水) 09:06:21.89

言いたいことも言えないこんな世の中じゃポイズン

**デフォルトの名無しさん** · 2020/03/25(水) 11:14:11.00

Cからprintln使ってるRustの関数呼ぶとメモリリークしよる(´・ω・`)

**デフォルトの名無しさん** · 2020/03/25(水) 12:42:04.62

>>277
それコメントの意味なくね？

**デフォルトの名無しさん** · 2020/03/25(水) 14:08:14.89

>>277
Personオブジェクトを返すって
-> Person
-> Box<dyn Person>
どっちのこと？

**デフォルトの名無しさん** · 2020/03/25(水) 16:36:38.82

今だにCopyトレイトの命名は失敗だと再確認する

**デフォルトの名無しさん** · 2020/03/26(木) 02:55:12.87

Box<T> は copy ではなく move なんだとさ。

**デフォルトの名無しさん** · 2020/03/26(木) 02:58:28.01

>>267
Option<T> は、Copy。
Box<T> は、Move。
だから、
Option<Box<T>> は、外側が Copy で、中身が Move らしい。

**デフォルトの名無しさん** · 2020/03/26(木) 03:37:08.94

中身がCopyのときだけOptionもCopyになるんじゃないの？？

**デフォルトの名無しさん** · 2020/03/26(木) 03:46:23.72

>>287
分からない。

**デフォルトの名無しさん** · 2020/03/26(木) 03:48:11.78

>>285
ソースを示しておくと、以下の公式(?)サイトに、
「because Box isn't Copy」という言葉が書かれている：
https://doc.rust-lang.org/nomicon/checked-uninit.html

**デフォルトの名無しさん** · 2020/03/26(木) 04:59:35.60

struct のメンバに local 変数を代入した場合、エラーになる？

**デフォルトの名無しさん** · 2020/03/26(木) 12:36:34.09

https://doc.rust-lang.org/std/option/enum.Option.html#impl-Copy

impl<T> Copy for Option<T> where T: Copy {}

**デフォルトの名無しさん** · 2020/03/26(木) 14:56:26.41

>>291
それは >>267 とちゃんと整合しているな。
Option<T>は、Copy と Cloneの両方が実装されていると言うことで、
ならば、原則論からすればOptionは代入演算子でMove動作「ではなく」Copy動作
だということになる。