Rust part13
レス数が950を超えています。1000を超えると書き込みができなくなります。
>>849
土地は複製できないけどそれの何が問題なの？
値として見るならCloneじゃない型と同じじゃないの？ >>848
これ知りたいね
単に引っ込みがつかなくなってるのではなく
真剣に複製されると思っているのであれば
何らか共通部分があるんだろうから >>849
そうすると所有権という情報には、型と値が含まれてるってこと？
その場合、値の変更は所有権の変更を伴うと考えている?
また、型と値が同じものはたくさんありうるけど、それらの所有権を区別するものはなに？ リアルな世界では土地もその所有権も複製できないけど
こちらの世界では値も所有権も複製できる
と考えるだけで矛盾なくRustを理解できると思います
そこに矛盾はありません こまけえこたあ良いんだよ！！ コンパイラ黙らせた奴の勝ち！！ >>852
それぞれ固有の値を持たないのであれば全部同じ「所有権」では？ >>847
＞「値と所有権が複製されて、別々の値と所有権になる」
別々のものになってて複製？
言ってて変だと思わんの？ そもそも発端は入門者向けドキュメント >>486 にて、「所有権の複製（コピー）」とかいう言葉が出てきてこれではダメだ、っていうのが発端だからね
入門者向けドキュメントなんだから、正しい言葉で、正しく伝わる表現をしてほしいのよ 結局のところ元の記事にあったように
「所有権とは、文字通り変数が値を所有できる権利のことです。」と間違って捉えてるってことだろうな >>858
それは正しいだろ
少なくともその解釈でRustの仕様と矛盾する点は何もない 土地は複製できないって主張もよくわからなくて
例えばコピー機は別に原子レベルで複製しているわけでもなく
人間が見て同じに見える程度に見た目を再現してるだけなわけで
同様に土地だって同じ形状に造成できるわけじゃん
だから複製というときにはオリジナルのどこを再現したかが重要で
何が共通部分で何が差異なのかをはっきりしてほしい >>857
複製ってのがそもそも別のものを作ることなんだが リソースの所有者はリソースを解放する責務がある
主としては値が変数に束縛されることで所有の関係が作られる
このへんをいろいろひっくるめて所有権の概念になるわけで、こういった概念である「所有権」そのものを複製したり作成するというのは、やはり言葉としておかしい
束縛関係を複製とか言われても意味わからん ここで"もの"かそうでないかを区別する意味ってある？その場合の"もの"ってなに？ 所有権とは所有にまつわるルールのことというのはTRPLに書いてある通りだと思うんだが
take ownership など、所有権という物をやりとりしているように読める文言はどう解釈すれば良いんだ？ 所有権の話はもう禁止してくれ、唾飛ばしながら「ワイが一番所有権分かってるぞ！」とかほんまどうでもいいわ
コンピューターサイエンス学科出でもないのに、もう駄コードを書く仕事に戻れ >>868 が言ってる通り公式ドキュメントと矛盾がないように書くべきでしょ
そうすると、copyするのはvalueであって、ownershipはcopyしない
ownershipはtakeしたりtransferするもの
>>866 の最初に書かれてることは良いけど、そのあとは意味不明 この自演おじさん、そこらじゅうで同じ芸風で荒らし回ってるから本当にタチ悪い。 結論：
｢所有権の複製｣は根拠の無いオレオレ用語であり
rust公式による定義は今回も一切示されなかった
でオシマイの話 >>868
take ownershipのownershipは”もの”じゃないよ
もうちょっと英語勉強したほうがいいんでは？ >>875
理由を言わず間違ってるとだけ指摘して勉強した方が良いとマウントとってくるいつもの人だ
反論できないから空っぽの指摘しかできないのかな unixのファイルシステムの権限周りの継承とかその辺とごっちゃになってんのかね？
どうして所有権をコピーみたいな話が出てきたのかわりと謎 謎だよな
C++から来てるわけでもないし
どこから来た発想なんだろう？ >>876
説明してもらっても聞く耳持たないから
もう理由は教えないみたいなことを言われてなかったか？ >>879
その説明へのレス番号貼るだけでもいいよ 所有権ルールと参照ルールを混同してたり
所有権が複製される構造はBox<T>のcloneと同じと言ってるところに
勘違いのヒントがありそうだか皆目検討がつかない
誰か解読してくれ ここまで見てる限りどっちでもOKな話だな
値と所有権が「!Copy型は移動」「Copy型は複製」との説明でもRustの理解に支障がないのも事実
一方で現世界にない「所有権の複製」という表現に違和感を持つ人が存在することも理解できる
ただし後者はあくまでも心の内なる話だから前者を崩せない限り不利っぽい >>886
いや、>>870 で正しいの書いてくれてるのに、公式でもそうなってるのに何故に頑なに所有権の複製を広めようとしてるのよ笑食べて 語感には個人差があるからな
個人的には「複製」といえばCopyじゃなくCloneだし、Cloneなら「所有権の複製」もぎりぎり許せる
Copyを無理やり日本語にするなら「複写」かな
Copyの何たるかは
https://doc.rust-lang.org/std/marker/trait.Copy.html
で十分説明されてると思う
>>881
「ファイルの所有権がある⇒ファイルにアクセスできる」
の類推で
「変数（値）の所有権がある⇒変数（値）にアクセスできる」
と誤解されるケースはたまにみかける
これは用語（訳語）の問題でもあるから多少は仕方ない Rustの公式ドキュメントを調べると "copy of the value" という表現はたくさん出てくるが、 "copy of the ownership" のような表現は見つけられない
おそらく公式ドキュメントでも "copy of the ownership" みたいな言葉が使われそうになったときは意図的に排除されてるんだろう
もし "copy of the ownership" みたいに変更しても問題ないと思うなら、公式ドキュメントのリポジトリでそういうふうに提案してみてくれよ
Contributionのガイドを参考にコミュニティに書いたり、GithubでPull Requestするだけだからさ
https://rustc-dev-guide.rust-lang.org/contributing.html ownership の take や transfer という言葉が出てくるのは !Copy な値についての説明で、
Copy な値については ownership 絡めて説明されてないよね
ownership rule 自体は全ての値に適用されるから本来は Copy な値の ownership についてとうルールが適用されるかという説明はあった方が良いかもね
元々の初学者向け記事ではTRPL英語版にない部分の説明をするにあたって所有権の複製という用語を発明したわけだけど
どう説明するとわかりやすいんだろうか >>886
>Rustの理解に支障がないのも事実
めちゃくちゃ支障が出てますやんw
所有権が複製されると思ってるからRustの基本ルールが理解できない >>836
所有権が複製されると思ってるからThe Bookの意味が取れない >>868 >>888
Rust的には「変数（値）の所有権がある」という表現が既におかしいぞ >>890
> 元々の初学者向け記事では(中略)所有権の複製という用語を発明したわけだけど
オレオレ用語を初学者に平気で刷り込んで平気ならば
> どう説明するとわかりやすいんだろうか
今後一切あらゆる場所で説明などしないでほしい 個人が複製を分かりやすいと思うのは自由だけど
初心者に広めるのはダメだと思うがな
もっと明らかに初心者向けの例え話とわかるような用語ならともかく
いかにも公式の技術用語っぽい見た目をしてるわけで
これを知った初心者がもっと深く知りたいと思ったときに
ググっても全く情報は出てこないし、誰かに質問しても「なにそれ？」ってなる
少なくとも公式の説明に沿った言い方なら、それで理解してる人が
大勢いるから、そういった問題は生じない 自分の理解不足を何で公式の落ち度みたいにすり替えてるんだ。間違いを認めたら死んじゃう病なの？ >>881
Box<T>が出てくるあたり所有権を値へのポインタ的なものとして考えてるのかもな
まあそれでも複製はされないからイミフには変わりないんだが 勘違い勘違い言うけど>>808以上の話じゃないように思うんだが。 自分も>>808で良いと思うけど公式の説明と表現が同じになってるかは気になる >>808
>>「値が複製されるとき、複製された値には新しい所有権が生まれる」と表現すべき
だからそれが間違っている
値には所有権は無い
入れ物に対して所有権がある
例えば&mutはその入れ物に対する書き換え可能な参照つまり所有権の借用
>>808を肯定する連中はRustをわかっていない 複製オジが遂に撤退戦をはじめたかw
なんで所有権が複製可能だと思い込んだのか説明してくれれば
他の人の役に立つのにな >>900
｢入れ物に対して所有権がある｣も微妙な表現で
｢入れ物となる変数が複製された値の所有権を持つ｣の方が適当だと思うけど、どう思う？ 流れぶった切ってすまんけど質問
｢借用｣と｢参照｣の違いってなんなん？ >>902
値は書き換わる物
だから値に所有権はない
入れ物に対して所有権がある
解放する対象も入れ物であってその値ではない >>904
c言語のfreeって明らかに値を解放してるように思えるんだが
freeした値はその後使えないがその値を入れていた変数はその後も使える ownerに対する所有権があるような話になってよくわからんね。 >>903
参照は変数の種類で、借用は参照の使い方とか参照同士の関係とか状態のこと。
明確に書かれていないけど、そのへんを意識してThe Bookのreferences and borrowingあたりを見ると良いよ。 >>905
C言語のfreeでも入れ物を解放している
入れ物の中にある値を解放しているわけではない
そしてmalloc/freeで対象となる変数は入れ物を指している
つまりその変数自体は一つ階層が異なりポインタである
そのポインタ変数を書き換えても別の入れ物を指すようになるだけ
入れ物の中身が書き換わるわけではない >>908
いいえfreeは入れ物にある値を解放しています
入れ物を解放しているわけではありません
そもそもfreeに限らずc言語の関数はすべて値渡しなのでfree(入れ物)と書いたらfreeには入れ物にある値が複製されたのが引数として渡されて入れ物に関する情報は一切渡されません
c言語の関数が操作できるのはこの複製された値です
もし入れ物を関数funcで操作したい場合はfunc(&入れ物)と書きます
この場合も&入れ物という値が操作されます
繰り返しになりますがc言語はすべて値渡しなので決して関数に入れ物を渡して解放するなどと言った操作をすることはできません 解放されるのは値です
入れ物の参照を関数に渡すには&入れ物という表記を使いますが&入れ物も値です これは参照呼びと言われますがただの値渡しです
あなたは明らかにプログラミング初心者なのでこのレスが理解できるようになるまでこのスレには書き込まないでください >>909
それは君が抽象的なセマンティクスとポインタ等を介するコードの区別が出来ていない初心者だから理解できないのだろう
Rustではこの違いが特に大きいのでその区別を付けることが非常に重要 >>900
これは同意
何が何を所有してるのかという主語目的語を意識せずに
フワッと分かったつもりになってるからなんだろうね 俺は初心者なのでフワッとすら分かっておらず、このスレでは一体何が議論になっているのかよく分からない。 >>910
別に抽象的なセマンティクスでもないよ
君が言っている「入れ物」でさえ操作的意味論的にはアドレスを表す単なる「値」として表現されていることを知るべきだね
ちゃんと理論的にはどのように定式化されているのかを知らないで入れ物だとか言った自分の無知を埋め合わすために勝手に導入したオレオレキーワード使って他の人を困らせてる辺り一向に君は初心者から脱却できないと思うよ
「入れ物」(笑)なんかじゃなくて実際に使われているテクニカルタームを使うことから始めれば？
知らないの？ 学術的に使われた用語だからテクニカルタームではないな freeに渡すアドレス値を「入れ物」と呼ぶか「値」と呼ぶかでもめているように見える >>914
その理解はおかしいよ
例えば
struct S(i32);
struct SS(i32, i32);
let i = 100;
let s = S(200);
let ss = SS(300, 400);
let a = [500, 600, 700];
この時にあなたの理解だと各変数に入っている「値」はアドレスなの？
もちろん生成コードにおいてスタック上のアドレスが用いられるのは事実だけど
Rustというプログラミング言語のレベルではそのアドレスは出てこずに抽象的に捉えるべき話でしょう >>918
それらの変数にはすべてそれぞれの実体が入っています
アドレスではありません
全ての「アドレス」は「値」ですがだからといって全ての「値」も「アドレス」であるとは言っていません
まずは読解力を身に着けましょう
もっと正しく理解をしましょう >>919
では、あなたの主張するアドレスはどこに出てくるの？
let a = [1,2,3];
let v = vec![1,2,3];
どちらもアドレスではないですよね >>920
失礼しました
配列は先頭要素のアドレスが変数に格納されるでしょう
これだけで済む話です
抽象化なぞそもそも必要とされる余地はありません 所有権を持つのは値じゃなく変数
これはいいよね
オライリー本とかは少し違うけど
少なくとも公式は値が別の値を所有するとか
値が別の値の所有権を持つという考え方は採用していない
で解放のほうだけど
解放する対象はメモリ領域であって値でも変数でも無いよね
便宜的に「変数(の指してるメモリ領域)を解放する」とか
「値(が格納されてるメモリ領域)を解放する」という言い方をすることがあるだけ >>921
それも違う
配列の先頭要素のアドレスが変数に格納されているわけではない
Rustではもっと抽象的なセマンティクスでプログラミングをするし配列の長さも持つ 値に対する所有権を変数が持つってことなら>>808は特におかしいとは思わないが？
逆に「入れ物」(変数？)に対する所有権とか言っている>>900の方が理解しにくい。 >>922
私は操作的意味論のモデルに乗っかって表現したまでです
操作的意味論ではメモリ領域を示すアドレスは値として表現されています
ある特殊な操作的意味論で定義された理論をベースにしているRustでメモリ領域のことを値だと表現するのは間違っていないでしょう
逆に入れ物や変数だといった表現をこの文脈で使うのは言語道断かと思われます >>921
それは違いますよ
そこでアドレスという考え方はしませんし、実装で見ても間違っています
例えばあなたの考えでは以下の4つの変数のうちアドレスとなるのはどれですか？
struct S(i32);
struct SSS(i32, i32, i32);
let i = 100;
let s = S(200);
let sss = SSS(300, 400, 500);
let a = [600, 700, 800]; >>923
すいません
さらに配列の長さも保持しているのならなおさら抽象化のレベルは下がりますよね？
自分が何を言ってるのかわかっておいでですか？
もしかしてRustの抽象化レベルってCよりも下なんじゃないんですか？(笑) なんでこのスレでは操作的意味論とC言語とRustをちゃんぽんして語ってるの？
みんな器用だね？ >>926
変数という用語も正しくはありません
まず第一にRustでは束縛と呼ばれます
正しく理解してください
それができないならばあなたはこれ以上スレに書き込まないでください
ちなみに私がアドレスだと言っているものはあなたが変数だと言っている物です
そもそもアドレスという表現も不適切なものですが悪しからず >>929
ついに馬脚を現したな
Rustでも変数(variable)と呼ぶことすら知らないのか
もちろん束縛(binding)も狭義の代入(assignment)と区別するために用いるが
そこでも束縛や代入の対象は変数である >>929
変数という用語で合っていますよ
早く>>926の質問に答えてください
Rustでアドレスという考え方をするあなたが間違っていると明白になりますから >>930
Rustの用語では束縛の対象は名前です
変数ではありません
Rustが便宜的に変数と使っているのは説明のためにユーザーにRustなりに歩み寄っているからです
あなたが「入れ物」だといったよくわからないキーワードを導入したのと基本的には理由は同じです
操作的意味論では束縛の対象は変数ですが代入の対象は変数ではありません
メモリ上のある位置です
便宜的に言えばアドレスです
再三の忠告になりますが正しい理解が出来ないのであればスレに書き込まないようおすすめします >>931
i,s,sss,aがアドレスです
まずは>>929を理解する読解力を身に着けてください
> Rustでアドレスという考え方をするあなたが間違っていると明白になりますから
逆にアドレスという考え方をしないのですか？(笑)
手続き型言語の重要な機能ですよ？
ocamlなどと言った非純粋な関数型言語にすらありますが(笑)
アドレスという考え方を他の言語利用者が使うのを許せないのであればこの機能がないHaskellなどをご利用してくださいとしか・・・(笑)(笑)(笑)
Rustには触れないでくださいね😂 >>933
残念ながら>>926の変数i,s,sss,aに入っているのはアドレスではありません
あなたが完全に間違っています >>934
変数i,s,sss,aにアドレスが入っているなどと言ってません
読解力も理解力もないんですね
i,s,sss,aは変数ではなくてアドレスという名の値だって言うことを理解できないとあなたはいつまで立っても初心者のままですよ？？(笑) >>934
間違っているのはあなたです
これで明白になりました 間違いを認めたくないおじさんが延々と言い訳するスレ ID:6AYXkq/G氏は
>>919で「それらの変数にはすべてそれぞれの実体が入っています アドレスではありません」
>>921で「失礼しました 配列は先頭要素のアドレスが変数に格納されるでしょう」
これで全く理解できていないことが露呈してからさらに暴走中ですね
>>935
Rustにおいてそれらの変数i,s,sss,aはアドレスではありません
抽象的な考えが苦手ですか？ >>939
Rustを含めアドレスという言語機能を持っている手続き型言語で変数と呼ばれているものはただのアドレスです
Rustでいう値が束縛された名前は操作的意味論における変数に対応していてあなた方がいう変数とは操作的意味論におけるアドレスを表現するものの対応物です
本来変数とアドレスは同義のものでc言語の規格で完全にポインタとアドレスが同じものとして扱われ区別されないのと同様に区別する必要性がないものです
現にポインタもアドレスも変数も操作的意味論では区別されていません
このあたりを理解できない限りID:6Qn4bKwUは永遠に初心者のままのようだ🤣 cのfreeは値「で」解放してるだけなんだけどなｗ
int *p = malloc(sizeof(int)); // 仮に p = 0x5617ae143260とする
free((int *)0x5617ae143260); // 値でfreeできる
値をfreeしてるわけでもなく
入れ物を解放してるわけでもなく
値をfreeに与えてやってあとはむこうでうまくヒープを解放してくれる
ヒープ解放のきっかけを値で指定してるだけ >>941
横レスだけど
仮にこの世にコンパイラも実行するマシンもなくて、Rustのコードだけが紙に書かれてたとして
それでもi,s,sss,aは変数ではなく、アドレスという名の値だって言い張るの？
具体的にはどういう値なの？ >>944
さあ？
実行するマシンが決まっているなら値はなんでもいいんじゃないんですか？
それこそ文字でも記号でもなんでもいい
その辺りの議論は操作的意味論の教科書で論じられていますよ >>945
なんでもいいの？
書かれているコードが>>926だとして、
iの値が0x5617ae143260で
aの値が0x5617ae143260でもあなた的には問題ないってこと？ >>947
新しいアドレスにはすでに使われているアドレスの値を使ってはいけないという制約は操作的意味論でも目にするでしょう
あなたが熱心に勉強するタイプの人であったなら私のレスを待たずにして自分で調べて自分で疑問を解決していただろうに残念ながらあなたは受動的にしか学習せず一生初心者のままに留まる人間なんでしょうね >>942
その通りで、単なる識別子としての「値」で解放しているだけだね
そしてアロケーションライブラリによってはその「値」がアドレス自体でないかもしれない、と
C言語では抽象レベルと具体化レベルがほぼ一致のためアドレスが使われアドレスで考えてもいいけど
多くのプログラミング言語ではその部分は実装レベルに隠蔽されているからアドレスで考えてはよくないね
で、話を戻すと、大元の話ではその「『値で』解放している」かどうかではなくて
「『値を』解放している」のか、「なんらか抽象的な『空間を』解放しているのか」の話だったと認識してる >>948
ごめん、プログラミング歴20年超えてるんだわ
まあ>>947は意地悪だったけど、何が言いたいかっていうと、
有効なアドレスってのは実行時するかコンパイルしないことには定まらないでしょって話
でも言語仕様っていうのは、コンパイラが存在しなかったとしても存在し得るんだわ
で、他の人は言語仕様の話をしてるけど、一人だけ変数じゃなくてアドレスという値だって言い張るから、
マシンが存在しない状態だとどういう値なのよ？って思ったのね
意地悪なこと書いてごめんよ おまえらって基本マジメなんやろな何か
意見の違いはあれどそんなに嫌いじゃないわ
（ただし複製おじは除く） レス数が950を超えています。1000を超えると書き込みができなくなります。
