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/24(金) 23:51:09.77

参照はそれが具体的な値としてやりとりされるときはアドレスになるのはわかるけどさ
参照とアドレスを同一視する教え方はよくないね
あまりにも実装寄りの考え方

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

>>893
で、そのprimary referenceには所有権の定義はないんですよね？
なぜなのかな？

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

>>891
> 変数には限られない何か
そんな定義があってたまるか

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

最適化をかけると生成コード上では実体としてのポインタが消えたり消えなかったりするとか言ってる奴が
リファレンスの定義の話をしてる奴を「あまりにも実装寄り」とか言い出すのギャグだろ

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

値の所有権は所有する変数のスコープで尽きるけど、
参照値の所有権は参照先の値より長く生存できない点でちがっていて特殊
だから入門書のそこで参照の所有権という言葉を持ち出すのは混乱の元かな

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

>>852
それは突っ込みどころを間違えてる
仮の所有権を参照の所有権と言い換えても
「原本および参照の所有権がすべて放棄された時にオブジェクトは破棄されます．」
となって間違いが悪化してしまう

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

>>899
それはそうだね
俺は「仮の所有権」を「参照の所有権」に言い換えろなんて言ってないけどね

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

>>899
キミは頭悪いんやから黙っとき
これはイヤミじゃなくて助言な

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

>>900
では言い換えるでもなく訂正するでもなく改善案となっているわけでもなく何をしたかったんだ？
唐突に頭悪いとか言い出すのは異常者か

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

>>902
「仮の所有権とか言われても困る」という感想を書きたかったんだよ
訂正や改善案を出したいなら5chじゃなくて著者の問い合わせ先とか出版社の編集部とかでやった方がいいんじゃない？

あと >>901 は別人ね、お前が信じるか信じないかは知らんけど

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

仮の所有権と書かれているのは借用のことを言いたいんだなーってわかる気がする
でもそこで参照の所有権はちょっと違うような違和感

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

参照に所有権？　それはそれで当然あるやろ
ってとこまで到達してる人と、できていない人

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

参照することと所有することを区別するのをやめやがったのがJava
これを思い出せる人と記憶がない人の認識がずれてるんじゃないの

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

>>905
それ以前にオブジェクト(値)が破棄される話で参照の所有権は一切無関係やん

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

参照型の変数がスコープから外れたらただ単に「参照の値」がドロップされて参照先の値には影響を与えない
という話と
＞原本および仮の所有権がすべて放棄された時にオブジェクトは破棄されます．
の記述は普通に関係ある話だけどね

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

所有権の複製オジに加えて
仮の所有権オジが出てきて
ある可能性が出てきたな

人類にはRustはまだ早かった説
Rustを正確に使うどころか正確に理解することすら困難だった説

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

GC言語では参照が生きてる限り参照先が消えないので意味があるけど
Rustで参照の所有権は意味がないよ

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

参照型の変数がスコープを外れたら何が起こるかって話だからRustでも意味あるよ

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

なんで明らかに理解できてないのにこんな自信満々なんだろうな
正直そのメンタルはほんの少しだけ羨ましいわ

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

>>910
意味のあるなしとかいう話かこれ？
参照にも所有権があるっていうだけの単なる事実でしょ
こだわるポイントが頭悪すぎない？

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

Rust初心者が参照にも所有権があるんだ！普通の値と同じようにスコープを外れるまで所有権があるんだ！と騒いじゃう気持ちは分かるがもちろん無意味
普通の値ならばブロックスコープを外れるまで移動しない限り所有権があるのはもちろんだが
参照の場合は全く違っていてNLL (Non-Lexical Lifetime)により参照が入っている変数が普通の値なら所有権を持ちつづけている状況でも参照の場合はは無効に成り得る
つまり参照の所有権というものを考えたとしてもその格納されている変数のブロックスコープの間に所有権が保たれる保証はなく参照の所有権を考える意味がないのだ
これが普通の値の所有権との決定的な大きな違い
さらに加えて参照は参照先の生存期間を超えられないルールもあるためこの観点からも参照の所有権を考えても単独存在は出来ず意味がない
したがって参照の所有権なんてことを自慢気に言い出す人はまだRustの基本を理解できていない

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

参照についてだけわざわざ所有権に意味があるとかないとか考える意味がない

参照の値は参照先の値よりも先に破棄されなければならない
という追加のルールはあっても、所有権や値にまつわるルールの例外であるわけではない
参照は値のサブセット

すべてのvalueにはownerがいて、ownerがスコープを外れたらdropされる
referenceも例外ではない

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

>>914
お前が所有権とライフタイムの区別がついてない初心者なだけやん……

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

>>916
ライフタイムが終わった時点で所有権も失う
所有権だけ単独で存在し続けられない

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

＞その格納されている変数のブロックスコープの間に所有権が保たれる保証はなく
コイツ所有権を「アクセスする権利」とかそういう感じで捉えてるのか
仮の所有権おじさんと同類じゃん

ownership って
値に対して ownership を負ってる奴はスコープから外れるときに値をdropしなきゃいけない
って責務の話であってアクセスする権利とかじゃないから保たれる保証がどうとか的外れだよ

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

PhantomData<&'a T>は参照を所有しているに含まれますか？

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

あと二ヶ月くらいであの本が世に出るのか
胸が熱くなるな（野次馬根性）

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

>>918
アクセスする権利なんてひとこも言っていない
妄想で叩き出すのは人として外れている

あと参照&T &mut Tに特別なdrop処理はない
だから参照のdropを考える必要はない

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

>>921
アクセスする権利とかそういう類のものじゃないから「所有権が保たれる保証」とか的外れだし

特別なdrop処理があろうがなかろうが値はdropされるし
考える必要がなかろうが参照もownerがスコープをはずれたときにdropされるよ
dropされるのはただの事実だよ、ただの事実なので考える必要があるかないかはどうでもいいよ

**デフォルトの名無しさん** · 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

うーめ