Rust part19

**デフォルトの名無しさん** · 2023/01/17(火) 12:41:32.25

公式
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/

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

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

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

前スレ
Rust part18
https://mevius.5ch.net/test/read.cgi/tech/1670663822/

**デフォルトの名無しさん** · 2023/02/22(水) 19:30:38.74

moveがふさわしい
ドキュメントでも至るところでmove or copyと対比され使われている
transfer or copyではおかしい

**デフォルトの名無しさん** · 2023/02/22(水) 22:03:03.74

moveやcopyの対象はvalue
ownershipはtransfer(譲渡/移転)されたりtake(取得)するもの

moveとcopyが対比されるのは同じ対象について述べているものだから当たり前

**デフォルトの名無しさん** · 2023/02/22(水) 22:04:44.93

>>795
それな
そのことをずーっと理解できないやつがおって草

**デフォルトの名無しさん** · 2023/02/22(水) 22:32:54.84

同じことを言い合っていて、間違ったことを言ってる人もいなさそうだが、何をもめているのだろう

**デフォルトの名無しさん** · 2023/02/22(水) 22:43:58.95

>>795
それらのふるまいの違いを明確にしないとただの言葉遊びに見える

**デフォルトの名無しさん** · 2023/02/22(水) 22:46:55.03

>>793だけ理解できていない
Rustで使われているmoveという用語は所有権が移動することで値が移動する概念を指す
例えばエラーメッセージのmove occursなどのmoveはその事象を指している
だからそこはtransferではなくmoveで正しい

**デフォルトの名無しさん** · 2023/02/22(水) 22:59:45.22

RustはC++から輸入して所有権って言葉を使っているだけであって
C++で言う「所有権を失ったがオブジェクトとしては存在している」みたいな状態は少なくともsafe Rustには無いからね
だから値と所有権を切り離して考えるだけ無駄

**デフォルトの名無しさん** · 2023/02/22(水) 23:28:17.85

値と所有権を切り離して考えてもムダなのはその通りだね
値には必ず所有者(owner)すなわち変数が対応してる
そして所有者である変数がスコープを尽きて消えるときに値もdropで消える
だから切り離すことはできない

値が消えないためには所有者である変数のスコープが尽きる前に、他の変数へ代入か、関数引数渡しか、関数戻値返し、をしなければならない
その時にCopy実装型だと値が複製されて渡した先にも別の所有者が生じて各々が別の人生を辿る
!Copy実装型だと値が「概念的に」移動して渡した先に所有者が変わる
この両者の違いを端的に表した用語がcopyとmove

**デフォルトの名無しさん** · 2023/02/22(水) 23:31:46.84

所有権が「移る」という意味の英訳として「move」という単語を当てるのが間違ってるわけではないが
「所有権を複製する」といった致命的な間違いを生む原因になってるの可能なら避けた方が良い

**デフォルトの名無しさん** · 2023/02/22(水) 23:55:25.59

>>802
いや、所有権に対して直接moveと言っているわけではないんだよ
値の所有者(＝変数)が変わることを、視点を変えると、旧所有者から新所有者へ値が移動している、それはさらに視点を変えると、所有権が移動していると表現してもいいわけだけど、
それら視点は様々あるけど同じことを指してRustでは『move』と呼んでいる
だから所有権(ownership)という単語に対して一般的な英語の用法として動詞にtransferやtakeを文章では使うけれど、そのこととは全く関係ない

**デフォルトの名無しさん** · 2023/02/22(水) 23:57:57.68

いや、そんな状態が無いはさすがに嘘か……
Option<T> where T: Dropのtake()は実質ムーコンみたいなことやるし

所有権=リソースの解放義務と考えればそもそも!Dropには所有権なんてものは存在しないって考え方が正しいのかねえ

**デフォルトの名無しさん** · 2023/02/23(木) 00:13:31.19

>>804
その場合も値と所有者は単体には生じてない
take()で新しい所有者に値が移動している
ただしデフォルト値のNoneにスワップされるため元の所有者も生きたままというだけ
これは一般的にはstd::mem::swap(),replace(),take()であり
互いに相手にmoveが生じただけ

**デフォルトの名無しさん** · 2023/02/23(木) 00:58:23.78

exeを実行するみたいなトートロジーは極めて有用だけどつまんないね

**デフォルトの名無しさん** · 2023/02/23(木) 00:58:28.47

やっと分かったかも
コードのある時点において、仮にその時点での継続を全部消したとき、Drop::dropが自動で差し挟まれることになるブロックはその時点でそのリソースを所有している、と解釈できるわけか

というのがNLL以前の話ってやつなんだなたぶん
そうなると所有の主体はブロックじゃなくてライフタイムってことになるのかね？

**デフォルトの名無しさん** · 2023/02/23(木) 01:29:31.74

どうしてドキュメントと違う言い回しの独自解釈を捻り出そうとしてしまうのか。

**デフォルトの名無しさん** · 2023/02/23(木) 01:50:57.31

複オジる　バレてあばれて　ぼけつほる

**デフォルトの名無しさん** · 2023/02/23(木) 02:02:47.49

>>807
値の所有はそれを他へ渡さない限りレキシカルにブロックスコープが尽きるまで続く
ただし参照のライフタイムについてはレキシカルなスコープではなく実際の使われ方に応じて短くなりうる
例えば非可変参照を使っていて、後から可変参照を使うことになった時は、
それらが重なってなければ非可変参照のライフタイムは終わった扱いにして、同じブロックスコープの中で新たに可変参照を借用できるのがNLL

**デフォルトの名無しさん** · 2023/02/23(木) 02:18:44.46

>>804
もちろん正しくない

**デフォルトの名無しさん** · 2023/02/23(木) 09:29:02.67

以前指摘されたDrop Obligationを今になって勉強して一人芝居してるw
ほんと滑稽な人やでww

**デフォルトの名無しさん** · 2023/02/23(木) 09:41:47.82

説明をわかりやすくするために創作された抽象概念と実装が1対1で結びついてるわけないのにね

**デフォルトの名無しさん** · 2023/02/23(木) 09:55:07.36

>>800
>「所有権を失ったがオブジェクトとしては存在している」
値が所有権を持ってるわけじゃないから

**デフォルトの名無しさん** · 2023/02/23(木) 09:57:21.40

C++のはmoveした後に抜け殻が残る話じゃね

**デフォルトの名無しさん** · 2023/02/23(木) 11:25:42.30

値に所有権フラグ的なものがくっついてるイメージでとらえてしまってるんでしょ
だからコピーしたら所有権も複製されるし
値と所有権を切り離して考えても無駄だと勘違いしてしまう
全部つながってる

**デフォルトの名無しさん** · 2023/02/23(木) 11:47:29.47

>>816
値と所有者はそれぞれ単独に存在できないので、値と所有者を切り離して考えても無駄なのはRustの基本たぞ
値は必ず所有者を持つし、所有者は必ず値を持つ

**デフォルトの名無しさん** · 2023/02/23(木) 13:08:38.52

複オジの常識は
Rustの非常識
このスレでは常識

**デフォルトの名無しさん** · 2023/02/23(木) 13:34:12.46

>>807
っていうかそこまで難しい話じゃなくて
move a value と transfer its ownership を同義語として、自然言語としてわかりやすいように適宜言い分けてるだけなのか？

じゃあ結局「ownershipとは～～」という形でのownershipの定義なんてものはRustにはない？
公式のドキュメント検索しても見つからなかったんだよね

**デフォルトの名無しさん** · 2023/02/23(木) 13:44:46.02

>>817で合ってるよ
オジ使いの人は文句をつけることが主目的なのか正しいことにも文句をつける印象

**デフォルトの名無しさん** · 2023/02/23(木) 13:46:51.41

不動産みたいな移動できないものの代わりにその所有権を移動する
メモリ上では実は複製と消去しかできないので本当は移動ができない

**デフォルトの名無しさん** · 2023/02/23(木) 13:56:15.25

>>821
そこの理解が重要だよね
あくまでもmoveは概念上のもの
だから皆が概念という単語を使っているね

>>799
> Rustで使われているmoveという用語は所有権が移動することで値が移動する概念を指す

>>801
> !Copy実装型だと値が「概念的に」移動して渡した先に所有者が変わる
> この両者の違いを端的に表した用語がcopyとmove

**デフォルトの名無しさん** · 2023/02/23(木) 14:13:14.00

そしてmoveの概念とは異なりmoveの実際の生成コードは最適化によって多種多様
基本はmove先に複製して元が無効となるけど、最適化によって複製が発生せずそのまま使ったり、
関数でサイズがある程度あるものをmoveで返す場合には、関数呼び出し元のスタック上に呼び出し先関数から直接書き込んでしまったりもする

**デフォルトの名無しさん** · 2023/02/23(木) 14:28:29.93

書けば書くほど的外れになっていくのが凄い
やっぱり基礎が重要なんだね

**デフォルトの名無しさん** · 2023/02/23(木) 15:57:28.87

言い掛かりつけるだけの人はこのスレ常駐の荒らしだから無視しとけ

**デフォルトの名無しさん** · 2023/02/23(木) 17:27:04.57

たまにはCloneのことも思い出してあげてください

**デフォルトの名無しさん** · 2023/02/23(木) 18:26:04.33

moveは値と所有権の移動
copyは値と所有権の複製
cloneは値と所有権の複製
borrowは値と所有権の借用
mut borrowは値と所有権の書き換え可能な借用

(๑•̀д•́๑)何ら問題ないｷﾘｯ
www

**デフォルトの名無しさん** · 2023/02/23(木) 19:16:28.85

所有権の複製って聞いておかしいと思わない子もそりゃいるよ
みんなが賢いわけじゃなくて残念ながらアホな子もそりゃいるんだよ
あんまりいじめてやるなよ

**デフォルトの名無しさん** · 2023/02/23(木) 21:37:16.18

弱者は強者に負けるとかいう理論もまた創作なのに
創作と現実が一致するまで戦争をやめられない現象は実際に起きている

**デフォルトの名無しさん** · 2023/02/23(木) 22:01:41.01

よほど誤解を招きやすい情報ソースがあるのか
それともここにはアホの子しかいないのか
はたまた一人が暴れているだけなのか

**デフォルトの名無しさん** · 2023/02/23(木) 22:02:05.98

C++のリファレンスカウンタの仕組みからやってないヤツにはちんぷんかんぷんだろうぜ

**デフォルトの名無しさん** · 2023/02/23(木) 22:14:56.65

経緯は>>770の通りだろうけどそんなに引っ張る話なのかがわからんね。
それで実害があるならともかく。

**デフォルトの名無しさん** · 2023/02/23(木) 22:23:17.99

病気な人が荒らすためのネタとしてやってるだけだろうからスルーが一番

**デフォルトの名無しさん** · 2023/02/23(木) 22:41:43.47

>>830
>はたまた一人が暴れているだけなのか
100%これ
数ヶ月このスレにいれば自ずとわかってくる

**デフォルトの名無しさん** · 2023/02/23(木) 22:51:26.41

オジ連呼の人だろ
放置でええやん

**デフォルトの名無しさん** · 2023/02/23(木) 23:14:02.76

>>823
Rustは様々な点で実装(生成コード)と概念を明確に分けてるね
概念の部分だけを保証するから最適化の余地が大きくて良い感じ

**デフォルトの名無しさん** · 2023/02/23(木) 23:43:30.64

概念にも最適化があって概念の「わかりやすさ」を最適化するために
moveとtransferどっちが優れた概念かを決めるバトルをやってたんだな

**デフォルトの名無しさん** · 2023/02/23(木) 23:58:17.97

>>837
Rustではその概念に対しては一貫してmoveを使っていてtransferが出てくるのは一般動詞として

**デフォルトの名無しさん** · 2023/02/24(金) 02:17:51.42

ひとり複製おじポエム

**デフォルトの名無しさん** · 2023/02/24(金) 06:23:24.59

Interface 2023年5月号予告
Cと比較して理解する質実剛健 Rust言語
3月25日発売 (定価 1,200円＋税)

**デフォルトの名無しさん** · 2023/02/24(金) 16:52:10.17

動かして学ぶ!Rust入門
発売日：2023年04月24日
定価：3,960円

【本書の概要】
Rustのプログラミング手法について、サンプルを元に手を動かしながら学ぶ書籍です。主に以下の3つについて丁寧に解説します。

●Rustの概要と開発環境
●Rustの基本的な文法と機能
●Rustによる簡単なアプリ開発

なお本書はエンジニアのための情報共有コミュニティ「Zenn」で公開されている大人気の「Rust 入門」を元にした書籍です。

【対象読者】
Rustに初めて触れるプログラマー

【本書のポイント】
・基本的な文法について丁寧に解説
・Rustの機能を学ぶのに適したサンプルを用意
・学習をもっと深めたい方に向けて「メモ」や「参照」で補足

【目次】
Chapter1 Rust
Chapter2 環境構築
Chapter3 Rustの文法と機能
Chapter4 アプリケーションの開発

**デフォルトの名無しさん** · 2023/02/24(金) 16:55:36.65

>なお本書はエンジニアのための情報共有コミュニティ「Zenn」で公開されている大人気の「Rust 入門」を元にした書籍です。

あーはいはい
結構です

**デフォルトの名無しさん** · 2023/02/24(金) 17:23:39.58

https://zenn.dev/mebiusbox/books/22d4c1ed9b0003/viewer/30450c
束縛
> let 文を使うことでオブジェクトと変数を束縛します．変数はそのスコープから外れたときに束縛していた所有権を放棄します．
> また，最初に束縛したオブジェクトの所有権は基本的に原本となり，原本および仮の所有権がすべて放棄された時にオブジェクトは破棄されます．

原本？
仮の所有権？

（＾ω＾）…

**デフォルトの名無しさん** · 2023/02/24(金) 17:52:16.90

これはまた凄いな
複製おじさん顔負けだわ

**デフォルトの名無しさん** · 2023/02/24(金) 18:03:47.03

少し読んでみたけど笑いを通り越して背筋が凍るんだが

ほんとにこれの書籍化？
URL間違ってない？

**デフォルトの名無しさん** · 2023/02/24(金) 18:06:55.78

借用のことを仮の所有権と呼んでるのか
ひでーな

**デフォルトの名無しさん** · 2023/02/24(金) 18:18:05.46

オレオレ用語満載の書籍が
初心者界隈に何をもたらしてしまうか…
発売前にぜひご一考願いたい（＾ω＾）

**はちみつ餃子** ◆8X2XSCHEME · 2023/02/24(金) 19:58:43.81

仮に (あくまでも仮に！) 完全に挙動を説明できているのだとしても
他の人が書いた説明と合わせて読もうとしたら食い違うわけだろ。
書いている人はわかりやすく言い換えてるつもりなんだろうとは思うけど
学習過程全体を考えたらあんまりわかりやすくなってない。

Rust の全てをカバーしてて他の資料を読む必要がないくらいに充実してるなら
独特の定義で押し通すのもありかもしれんが、現実にはそんなことありえないしな……。

**デフォルトの名無しさん** · 2023/02/24(金) 19:59:12.46

>>843
オブジェクトという単語は各プログラミング言語で様々な意味で用いられているが
Rustでその文脈で用いられることは少なく
その説明ではオブジェクトではなく値(value)とした方がよい

Rustで用いられるオブジェクトの用法の多くはtrait objectであり
Rustで重要なオブジェクト安全もtrait objectの話

**デフォルトの名無しさん** · 2023/02/24(金) 20:03:54.76

>>848
> 他の人が書いた説明と合わせて読もうとしたら食い違うわけだろ。
> 書いている人はわかりやすく言い換えてるつもりなんだろうとは思うけど
> 学習過程全体を考えたらあんまりわかりやすくなってない。

そうそれ
無駄で邪魔でしかない
独自用語を野放図に用いる傲慢さ
用語の正しさに対する誠実さが無い

**デフォルトの名無しさん** · 2023/02/24(金) 20:09:21.33

パーフェクトRust買った
これまで日本人の書いたRust本の中で1番良い出来だな
変なところに偏ってないし

**デフォルトの名無しさん** · 2023/02/24(金) 20:18:59.08

参照が入ってる変数は仮でもなんでもなく参照の所有権を持ってるのに仮の所有権とか言われても困る

**デフォルトの名無しさん** · 2023/02/24(金) 21:02:52.36

オブジェクトと所有権を切り離せないものと考えてる辺り>>800と全く同じ見解じゃん
ご本人様ではないですよね？

**デフォルトの名無しさん** · 2023/02/24(金) 21:17:18.19

たぶん参照自体じゃなく参照されてる値に対する「借用」のことを「仮の所有権」と表現してる

当然のように「オブジェクト」って言葉を使ってるけどもう少しvalueに寄せてほしいな

>> オブジェクト
>> 数値や関数や参照など，型の実体はすべて**オブジェクト**です．
>> つまり，式が返す値もまたオブジェクトになります．
>> 例えば， 1 という値も数値オブジェクトであり，1 == {1} という関係にあります．

ここの進次郎構文は何を表現してるの？
{1}が1なのはブロック式だからなんだけど

**デフォルトの名無しさん** · 2023/02/24(金) 21:17:49.67

>>800だけどちがうよ
所有権なんて存在しない見解だよ

**デフォルトの名無しさん** · 2023/02/24(金) 21:23:19.34

>>852
参照の所有権とは言わない
値に対する所有の唯一性が所有権で
値に対する参照が借用
そして所有＞借用の生存期間ルールを満たした上で所有のスコープルールとなるため、

>>843
>> 原本および仮の所有権がすべて放棄された時にオブジェクトは破棄されます．

この文章の各用語を「仮の所有権」→「借用(参照)」など全て正しく書き換えても根本が間違っている
この説明だと参照が残っていれば所有者がいなくなっても破棄されないことになってしまうため

**デフォルトの名無しさん** · 2023/02/24(金) 21:34:34.77

>>855
>所有権なんて存在しない見解だよ
所有権なんて存在しないてどういうこと？

**デフォルトの名無しさん** · 2023/02/24(金) 21:39:26.62

一個一個挙げてってもキリがないけど

> 所有権
> オブジェクトには所有権 (Ownership) が付いています．この所有権には２つの属性があります．

付いています？
二つの属性がある？

（＾ω＾）…

**デフォルトの名無しさん** · 2023/02/24(金) 21:40:16.86

「参照」なんて呼んだって中身はただのポインタだから
アドレス値という値を持ってるし、当然その値の所有権もあるし、
&TはCopyで複製される値だし、&mut Tは非Copyでmoveされる値だぞ

**デフォルトの名無しさん** · 2023/02/24(金) 21:41:37.97

>>853
値と所有者/所有権を切り離して考えるのが無意味なのは正しい
Rustでは値には必ず所有者が存在し、所有者は必ず値を持ち、これが所有権
それぞれ単独では存在できないため、切り離して考えることは無駄で意味がない

**デフォルトの名無しさん** · 2023/02/24(金) 21:46:41.92

>>854
何かしらの型の実体という意味で
オブジェクトという言葉を使ってるみたいだよ
値をオブジェクトと言い換えるくらいは可愛いもの

**デフォルトの名無しさん** · 2023/02/24(金) 21:50:54.34

複オジの系譜ここに極まれり

**デフォルトの名無しさん** · 2023/02/24(金) 21:50:55.01

これ推理するの楽しいな

型の反対はオブジェクト
式の反対は値
そうしないと値の反対が二通り存在することになりかねない

**デフォルトの名無しさん** · 2023/02/24(金) 21:52:47.93

>>859
もちろん参照は実際にはポインタとして登場することが多いけど、必ずしもポインタが登場するわけではなくその保証はない
参照という概念レベルでのみ保証されており、最適化でポインタなんて消えることも多いため、ポインタの存在を仮定してはいけない
もちろん値としての参照がCopy実装型で、可変参照が!Copyなのはその通り

**デフォルトの名無しさん** · 2023/02/24(金) 21:54:43.52

>>857
自分が見つけられてないだけなら先に謝っておくけど
Rust公式ドキュメントも含めて誰も(値の)所有権という言葉を定義していないように見えるんだ
つまりそんなものは無いんだと今は自分の中で結論している

とか書くと狂人判定されるんだろなあ、もういいけど

**デフォルトの名無しさん** · 2023/02/24(金) 21:57:38.30

>>864
？
&T と&mut Tはポインタだよ

https://doc.rust-lang.org/reference/types/pointer.html

Pointer types
References (& and &mut)

**デフォルトの名無しさん** · 2023/02/24(金) 22:03:23.59

>>865
https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html

Ownership Rules
First, let’s take a look at the ownership rules. Keep these rules in mind as we work through the examples that illustrate them:

・Each value in Rust has an owner.
・There can only be one owner at a time.
・When the owner goes out of scope, the value will be dropped.

「所有権」はownershipの訳語だから、このルールにおける「ownerであること」がownershipの定義と言っていいんじゃない？

**デフォルトの名無しさん** · 2023/02/24(金) 22:04:46.98

>>866
すまんね
そこでポインタをアドレス値と言ってるから、そういう具体的なアドレス値に必ずしも対応するわけではないという説明
もちろん型の分類としてはpointer型でその通り

**デフォルトの名無しさん** · 2023/02/24(金) 22:06:26.65

>>865
Rust公式本のここが分かりやすい
Ownership Rules
・Each value in Rust has an owner.
・There can only be one owner at a time.
・When the owner goes out of scope, the value will be dropped.

**デフォルトの名無しさん** · 2023/02/24(金) 22:07:32.25

すまん、>>867と被ってしまった

**デフォルトの名無しさん** · 2023/02/24(金) 22:12:54.01

>>868
具体的なアドレス値を利用していない場合に限っては最適化で消えることはあるけど
&Tも&mut Tも取り出したいときには中身のRaw Pointerの具体的なアドレス値を取り出すことはできるんだから
参照にポインタの存在を仮定してもなんの問題もなくない？

**デフォルトの名無しさん** · 2023/02/24(金) 22:26:37.20

>>871
アドレス値として取り出すこともできるのはもちろんその通り
しかしRustの参照の概念を初心者に教える入門でアドレス値を仮定した教え方は完全に間違いです

**デフォルトの名無しさん** · 2023/02/24(金) 22:36:10.73

Safe Rustの範囲内で raw pointer として中身のアドレス値を取り出すこともできるものを
アドレス値を仮定してはいけないと言われてもお前の個人的思想なんかシラネー

**デフォルトの名無しさん** · 2023/02/24(金) 22:42:58.52

俺も最初の頃は参照をアドレス値ポインタだと誤解してた
そしてRustではちょっとしたことまでわざわざポインタ経由でアクセスするのかよ無駄だなあと思ってたら
プログラムの生成コードを見るとアドレス値ポインタを使わずにちゃんと処理してた
参照はアドレス値ポインタを仮定しないもっと概念的なものであると今はわかるのうになった

**デフォルトの名無しさん** · 2023/02/24(金) 22:43:48.83

むしろC言語の知識があるRust初心者には
「参照はコンパイラが有効性をチェックする安全なポインタ」くらいの方が伝わりやすいと思う
メモリ上に値が保持されるならアドレスは存在するわけだし最適化でメモリにすら乗らないケースの方が特殊でしょ

**デフォルトの名無しさん** · 2023/02/24(金) 22:57:52.27

参照経由でアクセスしてもポインタ使わずに済むときはポインタ出て来ないから
参照はポインタではなくアドレス値が必要になった時だけポインタになるものじゃないかな
ポインタになる場合も含むもっと上位な概念かな参照は

**デフォルトの名無しさん** · 2023/02/24(金) 23:00:37.34

普通に公式がポインタだっつってんだからポインタなんだよ
お前の脳内ポインタ定義はどうでもええよ

**デフォルトの名無しさん** · 2023/02/24(金) 23:03:04.68

>>877
正しい
そしておまいはこのスレにしては珍しく聡明でレスも簡潔

**デフォルトの名無しさん** · 2023/02/24(金) 23:03:07.40

このスレ、マイルールを他人に押し付ける奴が多いな

**デフォルトの名無しさん** · 2023/02/24(金) 23:12:26.43

もうこの言語だいしゅき、ソートアルゴリズムの美しい実装でこだわり過ぎて目の下に幕ができそう♡

**デフォルトの名無しさん** · 2023/02/24(金) 23:14:18.16

ポインタ云々より「参照にも所有権がある」と言われたら初心者にとってはわかりにくいでしょ
所有権やそれに関連するルールを概念レベルで説明する際に
不必要に実装の詳細に依存すべきじゃないと思うよ

**デフォルトの名無しさん** · 2023/02/24(金) 23:17:10.37

このスレだったっけ？
以前クイックソートの実装でHaskellが最も美しいかどうかでレスバしてたのは？

**デフォルトの名無しさん** · 2023/02/24(金) 23:19:48.91

>>881
公式ドキュメントに
・Each value in Rust has an owner.
・All pointers are explicit first-class values.
とあって、 Pointer types のひとつとして References (& and &mut) が紹介されてんだから
参照にも所有権があるのは実装の詳細じゃなくて定義の問題だよ

参照はポインタの一種であり、ポインタは値の一種であり、すべての値にはownerがいるんだよ
公式ドキュメントで、実装ではなく公式ドキュメントでそう定義されてんだよ

最適化でポインタとしての実体が消えるとかいうのこそ実装の詳細に依存した話だよ

**デフォルトの名無しさん** · 2023/02/24(金) 23:21:40.39

The bookだと参照はポインタに似てるけどポインタとは違うと書いてあるね

https://doc.rust-lang.org/book/ch04-02-references-and-borrowing.html
A reference is like a pointer in that it’s an address we can follow to access the data stored at that address; that data is owned by some other variable.
Unlike a pointer, a reference is guaranteed to point to a valid value of a particular type for the life of that reference.

**デフォルトの名無しさん** · 2023/02/24(金) 23:27:50.41

>>884
もっかい貼るけど公式リファレンスね
https://doc.rust-lang.org/reference/types/pointer.html

Pointer types
All pointers are explicit first-class values. They can be moved or copied, stored into data structs, and returned from functions.

References (& and &mut)
(中略)
Copying a reference is a "shallow" operation: it involves only copying the pointer itself, that is, pointers are Copy.

公式リファレンスのIntroductionね
This book is the primary reference for the Rust programming language.

the primary reference って書いてるんだから食い違ったらどっちを参照すべきかわかるよね

**デフォルトの名無しさん** · 2023/02/24(金) 23:30:24.61

A reference is like a pointer in that it’s an address we can follow to access the data stored at that address;

The Book でも参照はアドレスだって言ってんじゃねーか！

**デフォルトの名無しさん** · 2023/02/24(金) 23:35:53.64

>>867
ではownerの定義はどこに？
何がownerになり得る？
ぱっと見ownerは変数だよと言えそうな気がするけど、temporary valueは束縛されないのでルールの例外になってしまう
MIRレベルだとtemporary valueも変数に束縛される（あってる？詳しくない）ならMIRレベルの変数がownerと言えるかもしれないけど、the Bookごときがそこまで考えて書いてると思う？

さらにRc<T>/Arc<T>はstd docやらnomiconやらで"shared ownership"なる表現を平気で使っていて、
そのOwnership Rulesを絶対視するなら2番目のルールに全力で中指突き立ててることになっちゃう、よね？
もちろんTを共有しているよって意図は自然言語から分かるんだけど、その所有は変数への束縛とはまた別だし、
術語としてのowner/ownershipの定義は曖昧に思えちゃうのよね

**デフォルトの名無しさん** · 2023/02/24(金) 23:36:51.47

>>885
それはポインタ型だな
参照が実際に受け渡される時は参照値となってポインタ型になるのは当たり前

**デフォルトの名無しさん** · 2023/02/24(金) 23:40:22.02

>>883
>・Each value in Rust has an owner.
↑これはThe Bookという初心者向けチュートリアルに書いてある概念レベルの話

>・All pointers are explicit first-class values.
> Pointer types のひとつとして References (& and &mut) が紹介されて
↑これらはリファレンスに書いてある実装レベルの話
後者は言語使用者に現在の実装を正確に伝えるためのもの
前者とは目的も抽象度も違う

The Bookでは参照自体をvalueと呼ぶことを意図的に避けてる
by valueといえば&Tや&mut Tは含まないTを指すように区別して書かれてる
初心者にとってのわかりやすさと実装を反映した説明の正確さを両立できない事情があるから

**デフォルトの名無しさん** · 2023/02/24(金) 23:44:20.54

実装依存の悪口を言うだけの方がじつはわかりやすいんだよね
建設的な造語や新ルールを提案したりしないから

**デフォルトの名無しさん** · 2023/02/24(金) 23:45:12.43

>>887
これも同じで初心者にとってのわかりやすさと説明の正確さが両立しないのでお茶を濁してる点
ownerを変数だけに限定してしまうといろいろ困る
‘static &strのownerとか

変数には限られない何かownerという概念的存在がいるんだ！！！ということで理解しといて

**デフォルトの名無しさん** · 2023/02/24(金) 23:45:39.79

>>883
それは値に所有権があるだけだぜ
そしてそれが参照の時はその本体より長生き出来ないんだから
「参照の所有権」なんて分かりにくい言葉は出す必要がない
それだと>>843の
＞原本および仮の所有権がすべて放棄された時にオブジェクトは破棄されます．
と発想が同じ

**デフォルトの名無しさん** · 2023/02/24(金) 23:46:25.60

>>889
＞↑これらはリファレンスに書いてある実装レベルの話
＞後者は言語使用者に現在の実装を正確に伝えるためのもの

お前の妄想は知らねえよ
https://doc.rust-lang.org/reference/introduction.html
This book is the primary reference for the Rust programming language.

現在の実装じゃなくて言語としてのRustについてのリファレンスだよ