Rust part13

**デフォルトの名無しさん** · 2021/11/07(日) 10:04:59.35

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

**デフォルトの名無しさん** · 2022/01/13(木) 16:12:14.47

ルー語で言うと｢ownershipがtransferされることをmoveって呼ぶ｣的な？

**デフォルトの名無しさん** · 2022/01/13(木) 16:19:48.57

this is known as a move.
英語のほうだと｢ムーブとして知られています｣か

実際コンパイラのソースみてもownershipはtransferとかtakeっていう表現でmoveだのcopyとは言ってないね

**デフォルトの名無しさん** · 2022/01/13(木) 16:53:50.81

>>549
公式リファレンスくらいは英語で読もうよ
そんな変なサイト見てるからOwnershipの意味すら取れなくなるんだぞ

**デフォルトの名無しさん** · 2022/01/13(木) 17:08:41.31

>>552
それは変なサイトではなくRust公式ページの日本語訳。
元のRust公式ページでも同様。

Ownership and moves
https://doc.rust-lang.org/rust-by-example/scope/move.html

Because variables are in charge of freeing their own resources,
resources can only have one owner.
This also prevents resources from being freed more than once.
Note that not all variables own resources (e.g. references)

When doing assignments (let x = y) or passing function arguments by value (foo(x)),
the ownership of the resources is transferred.
In Rust-speak, this is known as a move.

**デフォルトの名無しさん** · 2022/01/13(木) 17:27:36.08

>>553
Google翻訳にかけてごらんw
主語も目的語も受動態の意味もわかってないような翻訳はゴミ

**デフォルトの名無しさん** · 2022/01/14(金) 00:21:00.58

DeepL で翻訳してみた

なぜなら、変数は自身のリソースを解放する役割を担っているからです。
リソースは一人のオーナーしか持つことができません。
これはまた、リソースが複数回解放されるのを防ぐためでもあります。
すべての変数がリソースを所有するわけではないことに注意してください（例：参照）。

代入（let x = y）や関数の引数を値で渡す場合（foo(x)）。
リソースの所有権は移転する。
Rustの用語では、これを「移動」と呼びます。

**デフォルトの名無しさん** · 2022/01/14(金) 00:30:32.83

「所有権の複製」とか、意味の分からない事を書いている、香具師がいるのか？

**デフォルトの名無しさん** · 2022/01/14(金) 00:36:35.57

>>556
!Copyの場合は所有権がtransferされるのであれば
Copyの場合はどう表現すべきかという話

**デフォルトの名無しさん** · 2022/01/14(金) 02:45:20.76

>>557
元の値の所有権はそのまま、複製された新しい値の所有権が新しく発生する。
元の値の所有権について何も操作は行われておらず、表現すべきことも無い。

**556** · 2022/01/14(金) 03:32:18.88

所有権が複製されるという書き方よりも、むしろ、

primitive を含むコピー型変数は、コピーされると、
所有権は移動しないので、元の変数にもアクセスできる、みたいに使う

コピーされると新たに、別のオブジェクト(実体・メモリ領域)と所有権が作られるとか

**デフォルトの名無しさん** · 2022/01/14(金) 08:35:26.86

- 所有権ごと複製するという表現がわかりやすいかわかりにくいか⇒人それぞれ
- 所有権を複製するという表現が逆になにか問題を生ずるか⇒今のところ挙げられてない

**デフォルトの名無しさん** · 2022/01/14(金) 08:46:30.94

>>556
そう
「水素の音」みたいなもん
「水素の音」って言いたい人がいるだけ

**デフォルトの名無しさん** · 2022/01/14(金) 09:28:53.08

>>558
これだよな

**デフォルトの名無しさん** · 2022/01/14(金) 09:48:26.29

所有権の複製では意味が通らない事は明らかなので、
誰か >>489 の文をサクッと直してくれていいんだぞ

**デフォルトの名無しさん** · 2022/01/14(金) 09:59:56.29

流れ見てると｢所有権の複製｣は

おかしいから使うな派が半分
おかしいけどまあ好きにすれば派が半分
おかしくない派が約1名

みたいな感じ？

**デフォルトの名無しさん** · 2022/01/14(金) 12:13:02.65

この生産性のない議論に参加している人の割合と考えればさもありなん。

**デフォルトの名無しさん** · 2022/01/14(金) 12:25:28.10

>>564
どうでもいい派が抜けてる

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

>>560
全く別の所有権なんだからコピーとか言うとわかりにくいだろ。

**デフォルトの名無しさん** · 2022/01/14(金) 21:39:59.21

所有権というか、ポインタなのか、実体なのかって考えれば所有権もすぐに理解できると思うが

**デフォルトの名無しさん** · 2022/01/14(金) 22:02:26.42

>>568
それは所有権を理解してないのでは？

**デフォルトの名無しさん** · 2022/01/14(金) 22:22:42.07

>>:567
1つだったものが2つになることを複製と呼ぶのはべつにわかりにくいとは思わんがなぁ

**デフォルトの名無しさん** · 2022/01/14(金) 22:37:39.46

現実のものに例えると適する例がないけど
近い分野だとOSでのプロセスのfork()に近いかな
どちらも初期状態は同じでその後は別の道を歩んで値(メモリ)が別の値を取れるようになる
これをプロセスの複製と呼ぶから複製という単語自体はわかりやすいと思う

**デフォルトの名無しさん** · 2022/01/14(金) 22:45:21.62

>>570
だから「所有権」に関しては全く別物だろうがよ。。いつまでアホなこと言ってんだか。

**デフォルトの名無しさん** · 2022/01/14(金) 22:49:30.67

ジエンさんも複製されてるねw

**デフォルトの名無しさん** · 2022/01/14(金) 22:54:57.45

>>570
所有権は複製はできないが分割は可能
共有名義の不動産持分みたいなやつ
Rustに当てはめるとRcにあたる

**デフォルトの名無しさん** · 2022/01/14(金) 22:59:38.88

>>572
>だから「所有権」に関しては全く別物だろうがよ

「全く別物」という理由は？2つになるのは変わるまい。

**デフォルトの名無しさん** · 2022/01/14(金) 23:04:12.94

>>574
人それぞれだと思うが俺は所有権の分割って方がわかりにくいと思うがな。
Rcと紛らわしいから「複製」は使うなというのは納得できるが。

**デフォルトの名無しさん** · 2022/01/14(金) 23:08:16.48

>>571
プロセスはtask_structとかがあってしかも実際に複製されてるからな

Rustの所有権はそういうふうに実際にstruct Ownership;みたいのが有るわけじゃない
上の方でも言ってるやつがいるけどborrowcheckerとかのルールや制約を所有権って概念で説明してるだけ

だからメモリ上でCopyな(=単純なmemcpyで矛盾が起きない)型が複製されりゃ新しい所有権が作られるし!Copyな(=単純なmemcpyだと矛盾が起きる可能性が有る)型なら所有権もtransferされるってだけ
そこに解釈云々だのの余地はなく複製もクソもない

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

>>571
そこで言う複製は値の複製
forkしてもPIDは複製されないのと同じで所有権も複製されない

**デフォルトの名無しさん** · 2022/01/14(金) 23:13:06.72

複製という用語は、2つの実体が作られたよりも、
その2つの同値性が強調される

例えば、一卵性双生児は同一の遺伝子だから複製だけど、
二卵性双生児は複製じゃない。
単に、別々の2つの実体が発生しただけ

二卵性双生児間には同値性が無いから

ただ、文書を書いた外人は、copy を同値性という意味で使っていない

長文で説明するのが面倒くさいので、copyという短い単語で、
単に、2つの実体が作られたみたいに、気軽に使っているのだろう

だから、copyを翻訳すると複製になってしまう

**デフォルトの名無しさん** · 2022/01/14(金) 23:23:12.29

複製という訳の問題じゃないよね
「所有権のコピー」と言っても「copy ownership」と言っても何も変わらない

**デフォルトの名無しさん** · 2022/01/14(金) 23:34:11.11

PIDとか二卵性双生児とか、根拠や脈絡がない例え話が次々に出てくるのが笑える。
なんでそこまで必死なのかと。

**デフォルトの名無しさん** · 2022/01/14(金) 23:56:50.14

fork出してきたお前が言うなやw

**デフォルトの名無しさん** · 2022/01/15(土) 00:13:28.41

>>571は曲がりなりにも根拠らしきものを挙げているけど
>>578のPIDはまったくの根拠レスじゃん、
forkで複製されないものを探したらPIDが出てきたとかじゃね？

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

>>570
値はそうかも知れんが所有権は新しくできたものだろ。
新しくできたものを複製ってのは変だろうが。

**デフォルトの名無しさん** · 2022/01/15(土) 01:19:56.24

C++の例外をちゃんと扱うのは難しい、Rustのほうが簡単やろ

**デフォルトの名無しさん** · 2022/01/15(土) 01:20:44.09

スレ間違えた
まあいいや

**デフォルトの名無しさん** · 2022/01/15(土) 02:34:21.16

>>583
そう感じちゃうのがRustの所有権を理解してない何よりの証拠なんだよなぁ

**デフォルトの名無しさん** · 2022/01/15(土) 08:00:13.06

>>587
根拠を挙げて主張しているかそうでないかの違い。国語の問題。
所有権を理解しているかどうかは関係ないんだがお前さんの読解力にも問題があるな。

**デフォルトの名無しさん** · 2022/01/15(土) 08:48:58.88

根拠があるってんなら単にrust公式から定義をひっぱってくればいいのではｗ
それが無いから単なる珍妙なオレオレ用語で終了なんだよこの話は
こーいう手合いをいちいち構ってると時間足りないぞ人生は短いぞ

**デフォルトの名無しさん** · 2022/01/15(土) 09:24:09.35

>>588
複製おじさん必死だなww

**デフォルトの名無しさん** · 2022/01/15(土) 10:37:04.68

もう誰か本家のissueに｢CopyとMoveって何をcopy、moveしてるの？所有権のcopyっておかしい？｣って突撃してこいよw

**デフォルトの名無しさん** · 2022/01/15(土) 10:38:54.35

スレ追い切れてないけど所有権だけcopy/moveしてるという主張してる人がいるの？

**デフォルトの名無しさん** · 2022/01/15(土) 11:23:39.22

>>591
聞くまでもなくおかしいだろwww
何をcopy、moveしてるのかはチュートリアル読めよ

**デフォルトの名無しさん** · 2022/01/15(土) 11:24:43.51

>>592
複製おじさんちーっすw

**デフォルトの名無しさん** · 2022/01/15(土) 12:21:18.07

参照の説明に合わせてCopy Typeには所有権は無いという捉え方ならかろうじて理解はできる

**デフォルトの名無しさん** · 2022/01/15(土) 13:06:56.98

>>593
おれら匿名の有象無象におかしいって指摘されても聞く耳持たねぇみたいだから本家でぶった切られてこいっていう皮肉なw

**デフォルトの名無しさん** · 2022/01/15(土) 16:47:14.84

Cでポインタへのポインタをダブルポインタと言い張ったり
Cで関数へポインタで値渡ししてるだけのことを参照渡しと言い張ったり
酷いと思わんかね？
思わん人も居ることのほうが問題

**デフォルトの名無しさん** · 2022/01/15(土) 17:52:02.36

>Cでポインタへのポインタをダブルポインタと言い張ったり
>Cで関数へポインタで値渡ししてるだけのことを参照渡しと言い張ったり
c++でポインタ渡しを参照渡し言うならそりゃ誤解は出てくるが、そんなに問題にならんわ。
てか extern C で参照渡しは普通にポインタ扱いになるしな。
rustで所有権のコピー言うのは明確に意味がおかしい。

**デフォルトの名無しさん** · 2022/01/15(土) 18:25:43.70

もうええやろこの話題は…こんな枝葉の問題でギャーギャー騒いでたら何も身につかんで…
Rust棒を使って気に食わないやつを殴りたいだけなんか…？

**デフォルトの名無しさん** · 2022/01/15(土) 18:25:58.18

所有権 → リソースの解放義務
コピーしたらアカン

**デフォルトの名無しさん** · 2022/01/15(土) 19:00:19.86

c++23以降で契約プログラミングのサポートが入るらしいけど、rustって言語レベルで契約プログラミングサポートしてる？

**デフォルトの名無しさん** · 2022/01/15(土) 19:35:04.98

1週間以上も議論が続いている原因はおそらく
copyとmoveの対象の非対称性にあると思う

Copy trait非実装の型は「所有権がmoveされる」
Copy trait実装の型は「値がcopyされる」そして「新たな所有権が生じる」

**デフォルトの名無しさん** · 2022/01/15(土) 20:06:03.10

そんな複雑な理屈じゃなくてただのバカが意固地になってるだけだろ。。

**デフォルトの名無しさん** · 2022/01/15(土) 21:12:26.97

>>602
議論が続いてる気になってるんだw

**デフォルトの名無しさん** · 2022/01/15(土) 21:34:33.77

>>602
moveの対象も値だぞ
the bookのownershipの解説ページに1つでもmoveの対象がownershipになってる箇所あるか？
https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html

@ITの記事はそこも間違ってる

**デフォルトの名無しさん** · 2022/01/15(土) 21:37:55.34

>>600
ホントこれ
所有権が何かわかってれば複製なんて考えは絶対出てこない

**デフォルトの名無しさん** · 2022/01/15(土) 21:44:00.10

俺は中立派なので
「Copyトレイト実装型は値と所有権が複製される」
でも構わないし9割以上の人々にはこれで通じるだろう
あとはどこまでこだわるかだけだ
これ以上その表現は容認できないと続けるならばスレ荒らしと変わらない

**デフォルトの名無しさん** · 2022/01/15(土) 21:52:50.82

>>607
｢所有権の複製｣は根拠の無いオレオレ用語であり
rust公式による定義は一切示されなかった

でオシマイの話
議論ですらないし
どっち派という派閥の話でもない

**デフォルトの名無しさん** · 2022/01/15(土) 22:04:56.72

一般的に「批判や反対だけならバカでもできる」と言われるので
ここは代替案、修正案、改善案を示してはどうだろうか？

**デフォルトの名無しさん** · 2022/01/15(土) 22:09:17.84

匿名掲示板のやりとりで意見を変える人なんていないしとっとと次の話題に移るに限る

**デフォルトの名無しさん** · 2022/01/15(土) 22:17:16.04

複製おじさんが必死過ぎて草www
自分の間違いに気づいてもなお苦し紛れの言い訳テラワロスw

**デフォルトの名無しさん** · 2022/01/15(土) 22:29:40.11

>>597
参照渡しという用語は定義があるからCのポインタ値渡しに使うのは明らかに間違いなわけだが
ダブルポインタの方は正式に仕様で規定されているわけではないが俗語として通用しているな。
俗語だから前提無しに誰にでも通じるわけじゃないというところ注意が必要だが。

**デフォルトの名無しさん** · 2022/01/15(土) 22:30:43.34

複製おじさんは自演して複数人を装ういつもの人

いつも間違いを指摘されるが全く反省せず
嘘を書き続けて強弁しつつ自演擁護するのが趣味
C++じいさんと一緒にここに隔離されてる

**デフォルトの名無しさん** · 2022/01/15(土) 22:33:34.89

所有権も複製されるとするとrustの所有権システム破綻するの？
そういう話ではなくて用語の用法に違和感があるという議論だよね？
理解合ってる？

**デフォルトの名無しさん** · 2022/01/15(土) 22:44:35.60

>>614
その通り
俺は既に書いたように
『Copy trait実装の型は「値がcopyされる」そして「新たな所有権が生じる」』だが
これを『値と所有権が複製される』と表現する人がいても特に困らないしRustの理解で破綻することもない
現実にある所有権に照らし合わせると『所有権の複製』という用法に違和感があるだろうという話

**デフォルトの名無しさん** · 2022/01/15(土) 23:04:44.12

>>613
今日いきなり「複製おじさん」とかいう特異な単語を使う人が立て続けに現れたんですがｗ

**デフォルトの名無しさん** · 2022/01/15(土) 23:42:27.61

>>614
複製されたら破綻するよ
当たり前じゃん
所有権を何だと思ってんの？
わかってないの複製おじさんだけだよ

**デフォルトの名無しさん** · 2022/01/16(日) 10:16:15.91

>>614
＞所有権も複製されるとすると

所有権は複製されない。

**デフォルトの名無しさん** · 2022/01/16(日) 10:41:29.77

一週間バカにされ続けても自ら学ぼうとしないメンタルすごいよな

記事書いたやつも複製おじさんも所有権を変数単位のフラグみたいに認識してるんだよ
Copyなら変数の値をコピーして所有権フラグの値もコピーするイメージ(何か問題でも?w)

現実の所有権のように各所有権が個別リソースに紐づくと考えてないから「所有権を複製」しても問題ないと思っちゃう

所有権のメタファー台無し

**デフォルトの名無しさん** · 2022/01/16(日) 10:49:19.61

>>617
>所有権を何だと思ってんの？
この質問に答えられるようなら1週間前に終わってる話
自信がなくバカにされるのが怖くて答えられない
だから自演して印象操作に走ってしまう
それで余計にバカにされちゃう悪循環

**デフォルトの名無しさん** · 2022/01/16(日) 10:53:40.34

Rustスレは

仲介イテレータおじさん
所有権の複製おじさん
算数100点おじさん

の提供でお送りします

**デフォルトの名無しさん** · 2022/01/16(日) 10:57:58.12

みんなサビサビや!

**デフォルトの名無しさん** · 2022/01/16(日) 12:33:17.26

仲介おじさんと複製おじさんは同一人物でしょ

**デフォルトの名無しさん** · 2022/01/16(日) 14:09:05.15

しょーゆー拳！の複製とは・・・所有してない事では・・・？それとも共有？創造イテレーターおじさん。。。

**デフォルトの名無しさん** · 2022/01/17(月) 22:59:06.94

Rust 1.58で使えるようになったね

let var = 123.45;
assert_eq!(" 123.450", format!("{var: >10.3}"));

let vec = (5..=9).collect::<Vec<i32>>();
assert_eq!("[5, 6, 7, 8, 9]", format!("{vec:?}"));

**デフォルトの名無しさん** · 2022/01/19(水) 19:54:17.44

rust学習してるんだけど
コンパイル時検査で並列処理の安全性（可変参照が1つである事）を証明できるんだろうか？
実行時に借用チェックが行われてるという説明があったけどそれは必要なの？

**デフォルトの名無しさん** · 2022/01/19(水) 19:59:57.13

勘違いかも
この記事実行時にチェックしてるという意味じゃないかもしれない

**デフォルトの名無しさん** · 2022/01/19(水) 21:18:54.23

>>626
複数スレッドから参照される変数はコンパイル時に保証できないから実行時に保証されるよ
Mutexとか

**デフォルトの名無しさん** · 2022/01/19(水) 21:23:52.62

Rc<RefCell<T>>のように所有権が共有されてる値を変更する場合なんかは実行時チェックしかできない

interior mutability patternと呼ばれるやつはみんなそう

**デフォルトの名無しさん** · 2022/01/19(水) 21:24:20.06

ガブリンチョ

**デフォルトの名無しさん** · 2022/01/20(木) 10:26:42.45

実行時に動的に借用のチェックをさせたいという動機は分かるんだが
RefCellっていう名前でそれが表現できてると思えないし
一方で内部可変性を表現してるとも思えないし
そもそも内部可変性と実行時借用規則強制と二つのことが一つの名前になってるし
じゃあどうすべきだったということも思いつかないけど
なんかモヤモヤしてる

**デフォルトの名無しさん** · 2022/01/20(木) 12:30:05.06

Cell<T> は Mutable<T>
RefCell<T> は DynamicMutable<T>

Cellが何かを一度イメージできるようになると
今のネーミングでも困らないから名前が変わることはないと思う
interior mutabilityという名前も最初は分かりにくかった
こっちはまだ変わる可能性あると思う

**デフォルトの名無しさん** · 2022/01/20(木) 12:40:28.40

https://internals.rust-lang.org/t/pre-rfc-rename-refcell-to-give-it-a-descriptive-name/533
議論はあったが決定的な代替案があったわけでもないみたいね

**デフォルトの名無しさん** · 2022/01/20(木) 12:41:15.85

あー、なるほど、名前が分かりづらいのはおれが日本人のせいなのかな、とか思ってたけど、やっぱり慣れてないと分かりづらいネーミングだったか

**デフォルトの名無しさん** · 2022/01/20(木) 13:06:17.45

そもそもBoxってなんやねん！😡

**デフォルトの名無しさん** · 2022/01/20(木) 13:18:31.58

>>631
中身を書き換えられる『セル』という分かりやすい名前
Cellは内部可変がOK
RefCellは内部可変参照がOK

違いが分かりやすいように3種類を持つ構造体を用意
struct S {
a: [i32; 3],
c: Cell<[i32; 3]>,
r: RefCell<[i32; 3]>,
}
let s = S {
a: [1, 2, 3],
c: Cell::new([1, 2, 3]),
r: RefCell::new([1, 2, 3]),
};
// s.a = [4, 5, 6]; // コンパイルエラー (sがmutじゃないため)
// s.a[1] = 5; // コンパイルエラー (sがmutじゃないため)
s.c.set([4, 5, 6]); // OK 内部可変
{
let mut p = s.r.borrow_mut(); // OK 内部可変参照
p[1] = 5;
// このブロックを抜けるとborrow自動返却
}
assert_eq!([1, 2, 3], s.a);
assert_eq!([4, 5, 6], s.c.get());
assert_eq!([1, 5, 3], *s.r.borrow());

**デフォルトの名無しさん** · 2022/01/20(木) 13:20:34.04

メソッド名が動的←→静的と対称的であったりもしないし・・・

Cell: get, get_mut, set
RefCell: get_mut, borrow, borrow_mut

ただしget_mutはそれぞれ
https://doc.rust-lang.org/std/cell/struct.Cell.html#method.get_mut
> this method expects self to be mutable, which is generally not the case when using a Cell.
https://doc.rust-lang.org/std/cell/struct.RefCell.html#method.get_mut
> this method expects self to be mutable, which is generally not the case when using a RefCell.
とあり通常の用途とやらで考えると

Cell: get, set
RefCell: borrow, borrow_mut

共に"Cell"で内部可変性を表現しつつ
用途はメソッド名で十分わかるしまぁもういいのかこれで

**デフォルトの名無しさん** · 2022/01/20(木) 13:27:05.24

>>632
>>636
Cellっていう短い名前にクッキリした役割を描いたのはRust陣営は成功かもね
Rust以前に前例があるかどうかは知らんけど

>>634
名前の説得力が不足してる疑いはあるよね

>>635
それなｗ

**デフォルトの名無しさん** · 2022/01/20(木) 13:39:18.98

>>637
Cell⇔RefCell は静的⇔動的の関係ではない
Cell⇔RefCell は直接⇔参照の関係
そのため余分にRefが付く

静的⇔動的の関係にあるのは
「&」⇔「RefCell::borrow()」)
「&mut」⇔「RefCell::borrow_mut()」

**デフォルトの名無しさん** · 2022/01/20(木) 13:52:05.11

>>639
少なくとも構造体の説明としては

https://doc.rust-lang.org/std/cell/struct.Cell.html
> A mutable memory location.

https://doc.rust-lang.org/std/cell/struct.RefCell.html
> A mutable memory location with dynamically checked borrow rules

↑のように書いてあるね
だから
SCell // A mutable memory location with statically checked borrow rules
DCell // A mutable memory location with dynamically checked borrow rules
こんなんでもよかったんじゃないかなぁと思ったがこれはこれで石投げられそう

**デフォルトの名無しさん** · 2022/01/20(木) 14:13:35.66

>>640
それは違う
間違った解釈で無関係な場所に「with statically checked borrow rules」を付けてはいけない

参照借用規則『multi readers xor single writer』に対して
以下が「静的チェック⇔動的チェック」の関係にある
静的チェック: multi「 &」xor single「&mut」
動的チェック: multi「RefCell::borrow()」xor single「RefCell::borrow_mut()」

一方でCellとRefCellの関係は
内部可変性が「直接書き換えOK」⇔「参照書き換えOK」の関係
だからCellに対してRef(参照)が付くRefCellという名前になっている
そして参照となるRefCellに対してのみ上述の参照借用規則が適用される

**デフォルトの名無しさん** · 2022/01/20(木) 14:23:25.93

>>641
なるほどね

https://doc.rust-lang.org/std/cell/struct.Cell.html#method.get_mut
> If you require interior mutability by reference,
> consider using RefCell which provides run-time checked mutable borrows through its borrow_mut method.

↑ここでもまずは「参照による内部可変性が必要な場合は」と先に来てるね
「実行時に動的に借用のチェックをさせたいという」のが動機だと俺勝手に思いこんでたけど
それは一番じゃないみたい

**デフォルトの名無しさん** · 2022/01/20(木) 14:32:46.88

>>635
Cell/RefCellと違ってBoxは分かりやすくていい名前だと思うぞ
Boxing/Unboxingは他の言語でも普通に使われてるよね？
旧名のOwned<T>や代替案のHeap<T>に比べると確実にいい

**デフォルトの名無しさん** · 2022/01/20(木) 14:45:20.72

Boxing/UnboxingはC#やJavaにもあるからBoxには全く違和感なかったけど
よく考えるとソースコード上にBoxという文字列が出現するのはRustだけかも？

**デフォルトの名無しさん** · 2022/01/20(木) 14:54:02.35

Scheme でも次の規格に Box が入ることになっている。
(既に導入している処理系も結構ある。)

**デフォルトの名無しさん** · 2022/01/20(木) 15:32:21.48

通常の型TやBox<T>などがSend+Syncである一方
Cell<T>とRefCell<T>は!Send+!Syncであることと引き換えに内部可変性を得ている
つまりmutではない参照の内部にあったとしても
「Cell<T>」は「mut T」のように成れて直接書き換え可能
「RefCell<T>」は「&mut T」を得られて参照書き換え可能
ここでCellとRefCellの違いは「&」すなわち「Ref」だからこの命名自体は分かりやすいと思う

**デフォルトの名無しさん** · 2022/01/20(木) 16:52:16.46

>>644
むしろJava等にあるからこそ戸惑ったわ
既にあるBoxing/Unboxingへの理解に対して
Rustでは突如構造体としてBoxだもん

**デフォルトの名無しさん** · 2022/01/20(木) 23:14:12.74

まあBox と名前を合わせてBoxCellとか逆にBoxをRefにするかした方が統一的な名前づけだったとは思う。

**デフォルトの名無しさん** · 2022/01/21(金) 07:08:34.56

>>648
Box<T>はヒープ上にTの場所を確保してそこを指し示します
Cell<T>はヒープ上かどうかは無関係で例えば>>636の使用例では全てスタック上
したがって「Boxと名前を合わせてBoxCellとか」はおかしいです

TとCell<T>はメモリ上の格納場所も実体も同じです
つまりCellとは内部可変性という特性を与え示していると考えたほうがわかりやすいでしょう
RefCell<T>も同様ですがこちらは参照借用規則の実行時チェックのためのborrowフラグが余分に確保されます

もうひとつの「BoxをRefにするかした方が統一的な名前づけだったとは思う」もおかしいです
refは参照(reference)の略としてあちこちで使われておりヒープ上かどうかは無関係ですが
Box<T>はあくまでもTがヒープ上にあることが主眼です

余談ですがこの関係でRefといえばstd::cell::Refという構造体があり
これはRefCell::borrow()が返す型として直接意識することはなく使われています
ちなみにRefCell::borrow_mut()が返す型はstd::cell::RefMutです

**デフォルトの名無しさん** · 2022/01/21(金) 10:40:22.86

何も分かってねーなこいつ。
なぜBoxにするか、なぜRefCellにするかってのは要するに構造体のサイズを決定できない場合を想定してるわけよ。
スタックにそういういう動的にサイズが異なる実体をおくことも最近のコンパイラではないこともないが、通常はヒープに置くわ。
文字通りしか考えないで実際の使い方なんか一切考えないやつってのが丸わかりになるって意味では
分かってなさそうなやつにこの辺りについて問いただすってのは割と良いかも。