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/25(土) 13:54:21.62

>>922
普通の値の入った変数は他へ移動しない限りブロックの最後まで所有権があることが保証され最後まで自由に使うことができる
参照の入った変数はその参照が使われなくなったら無効となる使い捨てなのでブロックの最後まで所有権がある保証はない
例えばlet a = &T; f(a); let b = &mut T; g(b); let c = &T; の時点でもうaとbは使い捨てされており無効となり使えない
このように参照の場合は普通の値の場合と全く異なる
そして参照は使い捨てされてもdropで何か特別な処理があるわけではないため参照の所有権を考える意味がない

**デフォルトの名無しさん** · 2023/02/25(土) 14:11:50.12

>>923
＞所有権があることが保証され最後まで自由に使うことができる
＞無効となる使い捨てなのでブロックの最後まで所有権がある保証はない
＞無効となり使えない

・ブロックの最後まで使えるかどうか
・drop時に特別な処理があるかどうか

どちらも所有権の話じゃないね
ownership とは「値の owner がスコープから外れたら値はdropされる」というルールです
そのdrop処理に特別な処理が追加されているかとか、ブロックが終わる前に無効になるとか関係ないです

**デフォルトの名無しさん** · 2023/02/25(土) 14:45:07.44

参照に限らずCopy型はownership意識する機会が少ないからな
関数に参照の参照（&&T）を渡すみたいな例を考えないと参照値がborrowされた状態を作れない

>>923
「ブロックの最後まで所有権がある保証はない」ってあるけど
仮にブロックの最後で所有権がなくなってるような状況でブロックの最後にその参照を使う処理を追加したときに怒られるのは
ブロックの最後で参照を使った追加箇所じゃなく途中で参照先の値を横取りしようとした部分でしょ
これは「ブロックの最後まで所有権があって最後まで自由に使うことができる」ことにならないかな

**デフォルトの名無しさん** · 2023/02/25(土) 14:48:33.46

参照をフィールドに含む構造体が入った変数はブロックの最後まで自由に使えることは保証されてないけど所有権あるよね^^;

**デフォルトの名無しさん** · 2023/02/25(土) 14:58:04.64

>>924
理解できてるけど意固地になっているだけか
参照の場合はNLLでスコープがブロックではない見えないスコープとなり得て使い捨てできるから参照ルールを満たしてる限り前段は自由となるし
後段のdropは何も特別処理がないし
わざわざ参照の所有権を持ち出してくる意味がないことを理解できてるようだな

>>925
そこは明記が不十分で誤解させたようでごめん
参照先の値の所有権ではなく参照自体の話だよ
例えばそこの変数aのこと

**デフォルトの名無しさん** · 2023/02/25(土) 15:05:29.21

https://doc.rust-lang.org/reference/destructors.html
スコープの定義を探してこのページに来たが、ブロックの途中でmoveされた変数のスコープの終わりはどこなのか
ふつうに解釈するとブロックの終わりのようだが

"When an initialized variable or temporary goes out of scope, its destructor is run, or it is dropped."
これは「スコープを抜けたらdropする」じゃなくて「スコープを抜けたらdropされていなくてはならない」という制約の表現という解釈が正しいのかな
じゃないと二重解放にすることになっちゃう

**デフォルトの名無しさん** · 2023/02/25(土) 15:06:07.82

>>927
お前が言ってる
・drop時に特別な処理がない
・ライフタイムの制約があり、ブロックの最後まで使える保証がない
は参照だけじゃなくて「参照をフィールドに含むCopy構造体」についても同じ挙動なんだけどね

**デフォルトの名無しさん** · 2023/02/25(土) 15:09:11.46

>>926
なんだちゃんと基本を理解できていないのか
構造体のフィールドに参照を持たせる場合は構造体にライフタイムパラメータが必要となる
したがって参照をその構造体に入れた後にその参照が使い捨てされた場合(例えば後から可変参照を使う場合)はその使い捨て参照と構造体は運命を共にする
ブロックの最後まで所有権がないことはその構造体にimpl Dropした時だけコンパイルエラーなることから分かる

**デフォルトの名無しさん** · 2023/02/25(土) 15:10:49.55

>>930
参照をフィールドに含む構造体については普通に所有権を考える意味があるし、
それとまったく同じ挙動である参照についても所有権を考える意味があるね
終わりだね

**デフォルトの名無しさん** · 2023/02/25(土) 15:25:48.48

>>928
いや、この解釈もだめだ
ローカル変数をmoveで捕捉したクロージャを返す関数は関数のブロックスコープを抜けてもまだdropしちゃいけない

**デフォルトの名無しさん** · 2023/02/25(土) 15:27:46.31

>>931
え？
参照を所有しても使い捨てになるから参照の所有権を考える意味がない話だぞ

**デフォルトの名無しさん** · 2023/02/25(土) 15:34:30.90

>>933
スコープを抜けた時に束縛されたdropする責務があることを「所有権を持つ」って言うから
所有権の話にその値が使い捨てかどうかとかライフタイムの制約があるかとか考える意味があるかとか関係ないよ

参照を束縛した変数も、参照を保持する構造体を束縛した変数も、プリミティブ値を束縛した変数も、
drop時に特別な処理があってもなくても、ライフタイムの制約があってもなくても
いずれについても「スコープを抜けた時に束縛されたdropする責務がある」ので所有権はあるよ
意味があるとかないとかどうでもいいよ

参照を束縛した変数も、参照を保持する構造体を束縛した変数も、プリミティブ値を束縛した変数も、
いずれについても「スコープを抜けた時に束縛されたdropする責務がある」ので所有権はあるよ

**デフォルトの名無しさん** · 2023/02/25(土) 15:34:46.31

束縛された値、ね

**デフォルトの名無しさん** · 2023/02/25(土) 16:01:35.52

>>928
https://doc.rust-lang.org/reference/glossary.html#initialized
> Initialized
> A variable is initialized if it has been assigned a value and hasn't since been moved from.

一番最初に重要なことが書いてあったやつだすまぬ
つまりmoveされたらその時点でdrop scopeがなくなる=drop責務から解放される=所有権を失うと言えるわけね

**デフォルトの名無しさん** · 2023/02/25(土) 16:26:42.35

意味ないニキ（ID:sdtPy+yt）はもう
自分で何言ってんのか分かってなさそう

**デフォルトの名無しさん** · 2023/02/25(土) 21:23:46.93

>>930
ホントにそんなこと起きるのか疑問なので試してみたらマジにそうなった
誰かこうなる仕組みを教えて～

参照をメンバーに持つ構造体で実験
struct Foo<'a> {
x: &'a String,
}

fn main() {
let mut s = String::from("abc");
let mut foo = Foo { x: &String::new() };
foo.x = &s;
println!("{}", foo.x.len());
s.push('0');
println!("{s}");
}
ここまではコンパイルも通り動いた
参照を構造体メンバーに格納した後に
可変参照を利用となるpushをして普通に動いた

そこで書かれてる通りに構造体にDropを実装
impl<'a> Drop for Foo<'a> {
fn drop(&mut self) {}
}
するとコンパイルエラーとなった
つまり参照の所有権は使い捨て(?)とやらで意味がなく(??)
それを持つ構造体はブロックスコープの最後まで生きていないため(???)ということ？？
Dropの有無でエラーとなる仕組みがさっぱり分からない

**デフォルトの名無しさん** · 2023/02/25(土) 21:45:59.77

>>938
dropが実行されるときにxが利用される可能性があるから
s.pushの時点ではfoo.x = &sのimmutable borrowがまだ有効なのでmutable borrowはできませんよ
ということ

Dropがなければs.pushの時点でfoo.x = &sが使われる可能性はもうないから
immutable borrowの期間は終わってるものとして扱える

**デフォルトの名無しさん** · 2023/02/25(土) 21:56:28.48

>>934
>参照を束縛した変数も、参照を保持する構造体を束縛した変数も、プリミティブ値を束縛した変数も、
>いずれについても「スコープを抜けた時に束縛されたdropする責務がある」ので所有権はあるよ

現実にはスタックポインタをインクリメント/デクリメントするだけなので
挙げられてるような種類の変数にdropする責務や所有権があるかどうかは
初めての人への説明としてわかりやすいかどうかという主観の問題だよね

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

>>939
ふむむ
参照の所有権は自動的に打ち切られてしまい参照の所有権を考えても意味がないというのは正しいのですか？
impl Drop実装しなければdrop処理は無いと理解していいのですか？

**デフォルトの名無しさん** · 2023/02/25(土) 23:40:57.64

そうだろ
もちろん>>924の言う通り所有権は「値のownerがスコープから外れたら値はdropされる」というルールは常に適用できる
しかし参照については使い捨てができるためブロックスコープではなくルールを成り立たせるために見えない仮想的なスコープを用意してそこを外れたと考える本末転倒
そしてdropについても何もなされない
だからわざわざ参照の所有権を持ち出して来て考える意味がない
参照で重要なのは所有権ではなくmultiple readers xor single writerルール

**デフォルトの名無しさん** · 2023/02/25(土) 23:53:35.45

しかし、役に立たないことを知りたがる人間の方が
ある知識が役に立つ証拠が不十分と思ったら勉強やめる人間よりも安定しているかもしれない

**デフォルトの名無しさん** · 2023/02/26(日) 00:21:28.76

それはないな

**デフォルトの名無しさん** · 2023/02/26(日) 03:13:20.95

所有権とライフタイムとDropトレイトを全部ごちゃ混ぜにして覚えちゃってる困ったちゃん

**デフォルトの名無しさん** · 2023/02/26(日) 10:19:55.47

初心者になるのも大変だからなｗ
大体はそれ以前に転がされて終わるｗ

**デフォルトの名無しさん** · 2023/02/26(日) 10:47:51.71

実用レベルの達する前に学習者の9割が脱落してしまう言語
言語がRustだけになるとIT業界は終わる模様

**デフォルトの名無しさん** · 2023/02/26(日) 11:06:18.81

複オジも仮オジも無意味オジもみんなRustの被害者だった？

**デフォルトの名無しさん** · 2023/02/26(日) 11:13:58.37

誤解して入門を終えて実用的なプログラムを書けないで四苦八苦するのは個人の問題だからいい
でも間違った知識のままそれを主張するのは非常に迷惑

ポインターのミスでヒープをぶち壊してるような感覚

**デフォルトの名無しさん** · 2023/02/26(日) 11:27:18.64

>>947
その時はIT業界とRust業界に分かれるから大丈夫

**デフォルトの名無しさん** · 2023/02/26(日) 11:53:47.03

「所有権はdropする責務」の出典だけ分かればすべて腑に落ちる

**デフォルトの名無しさん** · 2023/02/26(日) 12:46:50.46

それでようやく理解できた
参照はdropで何もしないから責務がなくて使い捨てしても構わなくて所有権を考える必要ないと

**デフォルトの名無しさん** · 2023/02/26(日) 13:12:35.62

こいつもう地縛霊やろ…

**デフォルトの名無しさん** · 2023/02/26(日) 13:29:31.28

次スレってワッチョイつけたりしないの？
意図せずともID変わりがちな人もいるし追い辛いからつけてほしい

**デフォルトの名無しさん** · 2023/02/26(日) 14:25:35.83

参照についてだけ""わざわざ""、""特段に""、所有権について ""敢えて意識して""、""所有権について考えないようにする""必要性がない

**デフォルトの名無しさん** · 2023/02/26(日) 14:40:14.97

付けてもいいけどたぶんそれだと困る人はﾜｯﾁｮｲなしでスレを立てる
そしてそっちが伸びれば誰もﾜｯﾁｮｲありスレを使わない
そうしてできた残骸がすでに3スレある

立てたければ勝手にすればいいけど、ﾜｯﾁｮｲありスレだけを使い荒らしに反応しない強い意志が求められている

**デフォルトの名無しさん** · 2023/02/26(日) 17:46:02.01

>>954
>>956
次スレはワッチョイありを再利用すればいいよ。
ゴミスレ残したままなのは迷惑だし。

次スレ
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2023/02/26(日) 18:37:40.46

ﾜｯﾁｮｲ有無どちらのスレに書き込むかは各自の自由
ﾜｯﾁｮｲ無しスレは立てたい人がいればこのスレの後に自由にすればよいが
ﾜｯﾁｮｲ有りスレは既に3つもあるため4つ目を立てることは控えた方がよい

**デフォルトの名無しさん** · 2023/02/26(日) 19:27:42.62

IDコロコロ野郎に荒らされるよりはワッチョイでいいやろ

**デフォルトの名無しさん** · 2023/02/26(日) 20:16:02.76

ワッチョイあるスレは十中八九ネガティブ禁止の盲目信者専用になる

**デフォルトの名無しさん** · 2023/02/26(日) 20:39:47.94

ﾜｯﾁｮｲありが盛り上がってたらそっちに行くって言ってるのに誰も向こうに書かないじゃん

**デフォルトの名無しさん** · 2023/02/26(日) 21:10:15.97

マイナンバーにたとえるとお金バラまかないと無理なのでは

**デフォルトの名無しさん** · 2023/02/26(日) 21:13:21.05

自演対立や架空キャラ自演がやりにくくなるからこのままがいい

**デフォルトの名無しさん** · 2023/02/27(月) 08:54:14.39

次スレをワッチョイにして統合すればいいんじゃないの？

**デフォルトの名無しさん** · 2023/02/27(月) 19:38:38.14

すまんが、The Bookと比較してオライリー本ってどんな内容になってるの？

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

The Bookと比較すると
- 図や説明がわかりやすい
- カバーしてる範囲がやや広く説明も詳しめ
- C++との比較がやや多い
- IteratorやStringのメソッドの多くを一つ一つ説明しておりややくどい
- Rust特有のコードの読み方も書いてあって助かった (‘aはティックエーと読む等)

個人的には1点目がすごく大きかった
特にOwnershipとReferenceの章

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

オライリー本はRust始めた時に買ったけど一生積んでる

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

ここで少し中身を見てみれば？ amazonのlook insideより多く見れる
https://books.google.com/books/about/Programming_Rust.html?id=qlkzEAAAQBAJ

**デフォルトの名無しさん** · 2023/02/27(月) 22:07:50.00

>>966
最後わかる～

**デフォルトの名無しさん** · 2023/03/01(水) 09:54:37.52

Rcって値を所有してるの？
参照だから複数存在できる感じ？
規則と矛盾してて全く分からない

**デフォルトの名無しさん** · 2023/03/01(水) 12:37:59.53

>>970
同じ値を複数のRCで共有している。

Rustの場合、RCの「参照」は、参照と借用とか参照外しとかの「参照」とは別物と考えたほうが良い。

**デフォルトの名無しさん** · 2023/03/01(水) 13:03:01.05

>>970
共同所有

Rc::cloneで新しい共同所有者を追加する
共同所有者がスコープアウトすると共同所有者リスト的なものから削除される
最後の所有者がスコープアウトする際に所有してるポイント先もdropされる

**デフォルトの名無しさん** · 2023/03/01(水) 23:42:12.75

これを？オペレータ使った書き方するにはどうすればいいですか？
if let [first, second, third] = vec {
...
}
これでは上手く行きませんでした
let [first, second, third] = vec?;

**デフォルトの名無しさん** · 2023/03/02(木) 06:24:51.44

>>973
マッチしなかった場合どうしたいのか？
そのコードが含まれる関数の戻り値の型は？

**デフォルトの名無しさん** · 2023/03/02(木) 08:11:39.46

Rustに限った話じゃないけど低レイヤーに関する情報ってなかなか入手できない
Rustなら一応Embedded Rustがあるけど実践的にはいろいろ足りてない

**デフォルトの名無しさん** · 2023/03/02(木) 12:26:14.43

↓この人、美しいクレイピングを書ける！

**デフォルトの名無しさん** · 2023/03/02(木) 19:10:50.25

>>973
このスレでErr値を使わない時にif letやlet elseを使う、とあったのと同じで
Err値がない場合も同じようにこうする
let [first, second, third] = vec else {
return Err(...); // or None
};

>>975
話が曖昧すぎるので具体的に

>>976
クレイピングは知らん
scraper crateを使っている

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

相変わらず複オジの会話の噛み合わなさとオレオレ用語の使い方は異常だな

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

どこにオレオレ用語があるのか教えて

**デフォルトの名無しさん** · 2023/03/03(金) 00:39:13.95

>let [first, second, third] = vec else {
> return Err(...); // or None
>};
vecを直接マッチさせることはできないからsliceにする必要がある

それはいいとしてもvecを固定長のarrayにマッチさせて各要素を異なる名前の変数に入れるかエラーにするやり方はcode smellに感じる
vecが外部入力で変更しようがないのかもしれないがそれでも素直に長さチェックしたほうが良い

**デフォルトの名無しさん** · 2023/03/03(金) 00:48:28.99

一応次スレ立てた
Rust part20
https://mevius.5ch.net/test/read.cgi/tech/1677771928/

ﾜｯﾁｮｲスレならこっち
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2023/03/03(金) 01:01:26.40

>>980
スライスパターンとそのマッチングはRust公式リファレンスにも載っている普通の便利な用法
わざわざ長さチェックしていたらスライスパターンマッチングを知らない初心者かなと思ってしまう
さらに..パターンも併せて例えば
if let [.., ラス前, _] = s
これも公式に例として出ていて同様に長さチェックは不要

**デフォルトの名無しさん** · 2023/03/03(金) 17:46:26.59

>>973
moveしたいんなら
let [first, second, third]: [_; 3] = vec.try_into().map_err(|_| MyError::InvalidNumberOfHoge)?;
Vecを[T; N]にtry_intoした場合
Errの型がVecなのでmap_errしないと?が使えない

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

referenceでも同じ
let [first, second, third]: &[_; 3] = vec[..].try_into().map_err(|_| MyError::InvalidNumberOfHoge)?;

**デフォルトの名無しさん** · 2023/03/04(土) 00:46:15.62

結局？を無理に使うよりこの方が短く可読性もいいな
let [first, second, third] = vec[..] else {
return Err(MyError::InvalidNumberOfHoge);
};

**デフォルトの名無しさん** · 2023/03/04(土) 20:27:33.18

そんな使い方が許されるのは個人プロジェクトか使い捨てのコードだけだね

**デフォルトの名無しさん** · 2023/03/04(土) 21:28:46.68

ログファイルの各行をsplitして特定の項目（例：日時とIPとURL）だけを拾う処理とかで使えそう
Rustでは書いたことないけど

**デフォルトの名無しさん** · 2023/03/04(土) 21:42:49.00

>>986
Rustのリファレンス書の例>>986を許さない人こそ偏ってね？
そういう偏執者は代わりのコードどう書くんだ？

**デフォルトの名無しさん** · 2023/03/04(土) 23:13:10.54

>>986はいつもの荒らしだから無視しろ
荒らしは文句をつけるだけで修正案を出さない(出せない)から見分けられる

**デフォルトの名無しさん** · 2023/03/06(月) 11:51:11.89

>>987
使い捨てのコードじゃなければそういうのはcsv parserやargument parserを使って構造体に変換するからパターンマッチでは書かないよ

**デフォルトの名無しさん** · 2023/03/06(月) 12:45:03.92

それは用途によりけり
構造体にDeserializeする場合もあれば構造体を用意しない場合もある
パース用途以外でマッチングならパーサーが出て来る余地すらない

**デフォルトの名無しさん** · 2023/03/11(土) 12:38:09.48

誰も埋めてくれない...

**デフォルトの名無しさん** · 2023/03/11(土) 12:38:57.76

うーめ

**デフォルトの名無しさん** · 2023/03/11(土) 12:40:01.79

うめうめ

**デフォルトの名無しさん** · 2023/03/11(土) 12:41:44.36

うめーん

**デフォルトの名無しさん** · 2023/03/11(土) 12:43:10.68

梅太郎

**デフォルトの名無しさん** · 2023/03/11(土) 12:44:21.54

うめめめめめ

**デフォルトの名無しさん** · 2023/03/11(土) 12:46:24.71

うーめ

**デフォルトの名無しさん** · 2023/03/11(土) 12:47:53.90

めーう

**デフォルトの名無しさん** · 2023/03/11(土) 12:50:01.78

彡 ⌒ ミ
(´・ω・`)

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 53日 0時間 8分 30秒