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/20(月) 10:59:06.46

条件つき確率を信じない人のような印象
条件が成立しなければ普通の弾丸だから

**デフォルトの名無しさん** · 2023/02/20(月) 11:30:01.73

(ФωФ)

**デフォルトの名無しさん** · 2023/02/20(月) 13:36:11.72

「と言い出しそうだな」「って思ってそうだ」「な印象」

関心事がけっきょくは発言者の人格なんでつねえｗ

**デフォルトの名無しさん** · 2023/02/20(月) 17:13:31.56

5chの隅っこでとにかくマウント取りたいだけの人だから

**デフォルトの名無しさん** · 2023/02/20(月) 18:04:32.79

ただ文句をつけたいだけなのか
とにかく嫌いなだけなのか
ブロックラベル指定breakについてもlet elseについても反対してる人から一貫性や理性を感じられない面はある

例えばlet elseについて不要との主張の理由がこれまで3つ挙げられているが
「自分は使わないから不要」は論外として
「他の書き方ができるから不要」も特定の例にしか適用できない代替策だったり当然if letとlet elseはmatchに代替できる原点の視点を欠いている
「Err(e)値を扱えないから不便で不要」も同様でif letとlet elseはそれを扱わない構文だと理解できていない
もしif letも不要だと開き直るならばそれはそれで主張が一貫しているのであろうが

**デフォルトの名無しさん** · 2023/02/20(月) 18:35:32.36

ぱっと見の印象ほど便利でもないな
と言われてるだけのような気がするが

**デフォルトの名無しさん** · 2023/02/20(月) 18:38:50.78

理性と一貫性が一番欠落してるオジが何か言ってるぞwww

**デフォルトの名無しさん** · 2023/02/20(月) 18:59:27.30

冷静な技術的議論にならない原因が誰にあるかは一目瞭然なんだから相手にしないこと

分かりやすい煽りよりも技術的議論に見せかけたマウンティング行為にこそ高いスルー力が求められる

**デフォルトの名無しさん** · 2023/02/20(月) 19:34:52.06

煽りこそ要らない
技術的な議論なら歓迎
マウンティングとか興味ないためそんな発想も感覚も出て来ないので感じている人はたぶんそれ鏡の自分自身

**デフォルトの名無しさん** · 2023/02/20(月) 19:56:45.86

技術的論議とか不要やん
売れるシステム作ったもんの勝ちや

でもって世の中で売れてるシステムって意外とクソ技術

**デフォルトの名無しさん** · 2023/02/20(月) 20:36:10.20

>>746はきっとこの業界長いなｗ
昼間書き込んでる学生や無職どもとは面構えが違う

**デフォルトの名無しさん** · 2023/02/20(月) 20:50:17.61

>>746
ここはプログラミング言語Rustのスレ
興味がないならば別スレへどうぞ

>>747
昼間に書き込んでるIDを見たらあんたやでｗ

**デフォルトの名無しさん** · 2023/02/20(月) 20:55:08.90

>>748
勘違いしちゃいけない
言語には興味があるが今行われてる議論には興味も無いし意味もない

**デフォルトの名無しさん** · 2023/02/20(月) 21:14:07.07

何年も前からRFC出てて昨年stabled入りした機能に要るも要らねえもねえからな

**デフォルトの名無しさん** · 2023/02/20(月) 21:18:07.99

stableになった11月に不要だと暴れるならともかく
今になって不要だと暴れてるのも不思議だよな

**デフォルトの名無しさん** · 2023/02/20(月) 21:21:42.34

🦀

みんながインターネットで争ってばかりいるので、Ferrisくんは踊るのをやめてしまいました
お前のせいです
あ～あ

**デフォルトの名無しさん** · 2023/02/20(月) 21:31:44.32

RFCに特攻しないだけマシなのでは
いや公式に真正面からお伺いたてたほうがマシなのか

**デフォルトの名無しさん** · 2023/02/20(月) 21:53:45.15

暴れてる、ってのが被害妄想的表現やわ
俺には誰一人暴れてるようには見えない
このスレで暴れてたのは所有権の複製のあの人だけ

**デフォルトの名無しさん** · 2023/02/20(月) 22:53:31.02

繰り返し同じ主張をしても誰も同意してくれないから
自分の意見に同意してくれないやつらは全員暴れてるということにして無意識に自我を守ろうとしてるんだよ

自己愛的防衛とか躁的防衛というやつ

**デフォルトの名無しさん** · 2023/02/20(月) 23:30:32.01

>>754
所有権の複製ってもう5年くらい前だろ
そんな昔のことをいまだに引きずってるとは病んでね？
何の記事に書いてあった話かも忘れた

**デフォルトの名無しさん** · 2023/02/21(火) 00:09:04.47

自演オジ

**デフォルトの名無しさん** · 2023/02/21(火) 01:55:16.33

頭が良くなれば解決することを、性格や健康の問題だと思わないほうがいい気がする
頭が良くなりたいのは色々解決するからだ
マウントしたいからではない

**デフォルトの名無しさん** · 2023/02/21(火) 02:05:43.32

俺たちが興味あるのは技術の話題であって他人じゃねーもんな
誰がどうしたとか妄想に取り憑かれているとしか思えん
ところで標準ライブラリがflumeではなくcrossbeamを取り込んだのはなんでだ？

**デフォルトの名無しさん** · 2023/02/21(火) 10:55:47.93

https://github.com/rust-lang/rust/pull/93563
> crossbeam-channel has become the most popular alternative on crates.io

これ以上の深い理由はなさそう

**デフォルトの名無しさん** · 2023/02/21(火) 13:28:03.06

cargo check --doc-tests
　　　　　　　　欲しい！

**デフォルトの名無しさん** · 2023/02/21(火) 21:08:16.69

std::sync::mpscの実装が5年くらい放置されてた
その間に効率的な実装のcrossbeamが広まり更に効率の良いflumeも登場して性能と人気を競っている
放置されてた標準ライブラリを今回は実績のあるcrossbeam実装ベースへ変更したが状況は変わらないだろう
Rustは最小限の標準ライブラリに様々なクレートが競い合ってより良いものを生み出していく文化であるからだ

**デフォルトの名無しさん** · 2023/02/21(火) 21:14:33.40

ひとりごとおじさん

**デフォルトの名無しさん** · 2023/02/21(火) 22:02:42.80

自分の発言が炎上するかしないかを自分で判定できそう
失言おじさんにはそれができない

**デフォルトの名無しさん** · 2023/02/21(火) 22:06:41.15

ずっとおじさんおじさん言ってる「おじさん」おじさんの方が正直こわい

**デフォルトの名無しさん** · 2023/02/21(火) 22:08:33.85

分かってんなら触れんなっての

**デフォルトの名無しさん** · 2023/02/21(火) 22:20:06.54

オジおじ言ってる人は相手にしちゃいけないアンタッチャブル

**デフォルトの名無しさん** · 2023/02/21(火) 22:28:06.23

「所有権の複製」とかいうアホな用語を使って
ここのみんなにバカにされて涙目で敗走していったおじさんがおるんよ
その可愛そうな子が複オジ

**デフォルトの名無しさん** · 2023/02/21(火) 22:48:33.95

主語が小さいのは良い
長期戦すぎるのが悪い

**デフォルトの名無しさん** · 2023/02/21(火) 23:07:04.37

>>768
誰かが「所有権の複製」と言い出したのではなくITメディアサイトのRust入門記事に書かれていた話だな
その表現を許容できる範囲か違和感あるかで色んな意見があったのは覚えている

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

複オジ必死の自演2

**デフォルトの名無しさん** · 2023/02/21(火) 23:29:58.13

Copy実装型は値が複製されて新たな所有権が生じるが正確
それをその入門記事は所有権の複製と表現してたやつだろ
許容でも不許容でもどうでもええわ

**デフォルトの名無しさん** · 2023/02/21(火) 23:35:03.71

よっぽど悔しかったんやなｗ

**デフォルトの名無しさん** · 2023/02/21(火) 23:35:15.52

ところでいったいどうやってメモリ安全なの？

**デフォルトの名無しさん** · 2023/02/21(火) 23:39:30.48

緑の文字でMって書いとけばOK

**デフォルトの名無しさん** · 2023/02/21(火) 23:44:02.70

次のかたどうぞ

**デフォルトの名無しさん** · 2023/02/21(火) 23:44:49.64

そんな昔の話をいまだに引っ張ってオジオジ言ってたのかよ
精神病んでるな

**デフォルトの名無しさん** · 2023/02/21(火) 23:54:33.49

C言語は知ってる。アセンブラも知ってる。どうやってメモリ安全なのか
サクッと説明できないの？

**デフォルトの名無しさん** · 2023/02/21(火) 23:57:49.69

文句あるならRFCとか記事サイトとかに直接言うしかないな
ここでこれ以上の議論を続けてもしょうがない

**デフォルトの名無しさん** · 2023/02/21(火) 23:59:31.91

>>778
>>1

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

複製の方はググってみたらitmediaのRust入門記事だね
型に依って移動と複製の2種類あるのを教えるところだから、入門者向けの解像度として大雑把にしといて後で詳細を学べばいいでしょ

メモリ安全の方は解説記事が山ほどあるから、まずは読んで分からないところだけを質問したら？

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

参照されている間はmove禁止にする
それができたらその意味で安全
どうやってそれができるのか実装依存かな

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

稀に誤解する人がいるけど、moveはメモリ上の移動ではなく所有権の話だから注意ね
メモリ上の移動の禁止を保証するのはstd::pin::Pinだけど、初心者は知らなくても大丈夫

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

moveを所有権の移動だと捉えてるから
copyも所有権の複製だと勘違いする
これが世に言う複製おじさん

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

稀に誤解するオジ

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

>>783
一応ちゃんとCopyのdocで｢It’s important to note that in these two examples, the only difference is whether you are allowed to access x after the assignment. Under the hood, both a copy and a move can result in bits being copied in memory, although this is sometimes optimized away.｣って説明されてんだよな

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

所有権が移動するからその後はアクセスできなくなるんだよな

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

>>784
Copy非実装型は所有権が移動するで合ってるぞ
それをmoveと呼ぶ

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

メモリ安全に関しては実行時の、
すなわち実装上の工夫があるわけでは一切なく、
単にメモリの使途をコンパイラが把握できるようにして
コンパイラが厳しいチェックを入れるってだけのことなのかな
極めて有用だと思うけどつまんないね

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

安全性の証明をこの前目標にしてなかったっけ？

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

>>789
実装上の工夫をコンパイラが自動的に出来るように、メモリの使途をコンパイラが把握できるようにしているんじゃないの？

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

>>791
出来上がるプログラムのメモリ実装はC/C++並みに速く、
なのにそれはコンパイラの厳しいチェックをくぐってて安全
それだけのことでしょ

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

他言語由来なんだろうけど、moveという命名はセンス無いわな。
transferあたりならまだマシな気がする。

**デフォルトの名無しさん** · 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どっちが優れた概念かを決めるバトルをやってたんだな