Rust part11

**デフォルトの名無しさん** · 2021/06/17(木) 00:24:12.56

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

Web上の実行環境
https://play.rust-lang.org

日本語の情報
https://rust-jp.rs/

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※C++との比較は専用スレへ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

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

**デフォルトの名無しさん** · 2021/08/16(月) 16:57:08.35

>>632
それらメソッドチェーン部分ではもちろん使えるけど
iter系で指定するクロージャの中でも使えるんだっけ？

**デフォルトの名無しさん** · 2021/08/16(月) 20:57:35.53

>>633
Item が Option や Result なら ? は使えるけど
await は async fn か async block の中でしか使えないからほぼ使えないと思ってよさそう

**デフォルトの名無しさん** · 2021/08/16(月) 22:05:08.22

featuresは？

**デフォルトの名無しさん** · 2021/08/16(月) 23:25:05.01

>>634
?の方だけど、NoneやErrを除外してSomeやOkの皮を外すのはfilter_map使わないとメンドイね
例えばこんな感じで「?」はクロージャ内で使えた
println!("{}", std::env::args().filter_map(|x| std::char::from_u32(x.parse::<u32>().ok()?+110)).collect::<String>());

実行結果
$ cargo run 4 test 7 5 987654321 6
rust

**デフォルトの名無しさん** · 2021/08/17(火) 01:06:37.74

>>636
これは filter_map よりも map().collect::<Result<String, _>>() の方がよさそう

**デフォルトの名無しさん** · 2021/08/17(火) 01:42:37.78

全く関係ないけど、
for x in v
には、
for x in &v
for x in &mut v
for x in v.iter()
のようなバリエーションもあるようだけど、
for &x in v
のような書き方も出来るの？

あと、v と書いても v.iter() の省略なの？
この辺の話はどこに書いてる？

**デフォルトの名無しさん** · 2021/08/17(火) 01:44:24.62

>>638
ついでに、
let x = &y;
は、
let &x = &y;
let &x = y;
みたいに書くことも出来るの？？？

**デフォルトの名無しさん** · 2021/08/17(火) 01:46:10.93

>>638-639
左辺と右辺はパターンマッチで対応するメカニズムになっている。

**デフォルトの名無しさん** · 2021/08/17(火) 02:15:00.92

>>638
forの展開はこの辺とか。.iter()じゃなくて.into_iter()やね
https://doc.rust-lang.org/reference/expressions/loop-expr.html#iterator-loops

**デフォルトの名無しさん** · 2021/08/17(火) 03:20:14.87

この言語の敷居の高さの上げ方は異常すぎる。誰も全容分かってない

**デフォルトの名無しさん** · 2021/08/17(火) 03:39:07.39

C++ よりマシ。

**デフォルトの名無しさん** · 2021/08/17(火) 04:00:51.74

それだと最初のエラーを拾ってしまうけど今回はエラーになる引数を与えてそれらを無視して拾い集めるコード
もしエラーにならない引数だけを与えて成功するコードならばその方針もいいかも
あとfrom_u32はOptionを返すのでResultでなく全体をOptionにするとして
最後にunwrapも必要なのでmap().collect()のコードは以下になると思いますが
元の>>636より長くなってしまいますね

println!("{}", std::env::args().skip(1).map(|x| std::char::from_u32(x.parse::<u32>().ok()?+110)).collect::<Option<String>>().unwrap());
実行結果
$ cargo run 4 7 5 6
rust

**デフォルトの名無しさん** · 2021/08/17(火) 09:39:00.09

小中学生あたりでもわかる本ある？

**デフォルトの名無しさん** · 2021/08/17(火) 09:48:35.92

きったねぇコードだな

**デフォルトの名無しさん** · 2021/08/17(火) 13:39:50.79

参照型の変数xをlet文で新しい変数yの初期値にした場合、
let a = 123;
let x:&i32 = &a;
let y = x;
y は参照型になるんだっけ？
そもそも、最初の文は
let x = &a;
と書いても全く同じ意味だっけ？　さらに、
let x:&i32 = a;
と書いても同じ？

**デフォルトの名無しさん** · 2021/08/17(火) 14:30:13.21

>>647
試してみるといいよ
yの型を知りたければtype_of(&y)で

fn type_of<T>(_: &T) -> &str {
std::any::type_name::<T>()
}

let a = 123;
let x = &a;
let y = x;
println!("{}:{}, {}:{}", x, type_of(&x), y, type_of(&y));

**デフォルトの名無しさん** · 2021/08/17(火) 14:31:53.69

答えを知ってる人に書いて欲しい。
この言語、試してみないと型すら分からないんだったら困るな。

**デフォルトの名無しさん** · 2021/08/17(火) 14:35:58.73

>>647
> y は参照型になるんだっけ？
なる

> そもそも、最初の文は
> let x = &a;
> と書いても全く同じ意味だっけ？
ほぼ同じ
下だとaの型がi32に固定されない点だけ違う

> さらに、
> let x:&i32 = a;
> と書いても同じ？
これは全然違う
そもそも型エラーでコンパイルできない

**デフォルトの名無しさん** · 2021/08/17(火) 14:41:24.86

>>647
めちゃ基本的なことなので入門書を読もう

**デフォルトの名無しさん** · 2021/08/17(火) 14:45:56.55

本を読んだけど、明確には書いてなかったと思う。
let文に置いて参照型が右辺の場合、左辺も参照型になるということなのか。
ということは、letを書かない代入文で左辺に参照型で無い型を
書いて、右辺に参照型がある場合にはエラーになるのか？？？
わけが分からん。

**デフォルトの名無しさん** · 2021/08/17(火) 14:51:57.21

C++出身の人かな

**デフォルトの名無しさん** · 2021/08/17(火) 15:00:35.72

C++出身だ。
Rustにおける参照型の変数の規則性が分からない。

**デフォルトの名無しさん** · 2021/08/17(火) 15:06:15.30

>>654
Rustの参照はC++の参照じゃなくてポインタのほうが近いよ

**デフォルトの名無しさん** · 2021/08/17(火) 15:06:32.93

Rustから入る人や
色々な言語をやってきた人は理解が早い
しかしC++だけやJavaだけしか経験ない人は
自己中な思い込みが激しくて素直に学習しようとせずに間違った解釈したりして無駄な質問ばかりしがち

**デフォルトの名無しさん** · 2021/08/17(火) 15:06:36.98

Rustは例はあるが、ちゃんとした論理的な言葉や数式の様なもので、規則性が
書いてないのではない？
C++だともっと厳密に書いてある。

**デフォルトの名無しさん** · 2021/08/17(火) 15:10:48.52

>>652
何て本？

**デフォルトの名無しさん** · 2021/08/17(火) 15:11:29.96

>>656
そうではなくて、規則性を言葉で書いてくれ、ということだよ。
試してみてなんとなくの経験法則とかじゃなく。

**デフォルトの名無しさん** · 2021/08/17(火) 15:12:37.71

>>658
bookの印刷版も読んだが、途中読み飛ばしたページもあるが
読んだところにはちゃんと書いてなかったと思う。
数学的な規則が欲しいんだ。
文学的な言葉や例ではなく。

**デフォルトの名無しさん** · 2021/08/17(火) 15:13:56.74

>>657
そういう位置付けのドキュメントはこれだね
ただし冒頭にもある通り完全ではない

The Rust Reference
https://doc.rust-lang.org/stable/reference/

**デフォルトの名無しさん** · 2021/08/17(火) 15:15:28.48

>>656
まずはC++を忘れろ
思い込みは習得の邪魔になる
あるいは様々な言語をやってきていれば各言語で概念や書式や用語などが少しずつ異なることが理解できるはずだ

**デフォルトの名無しさん** · 2021/08/17(火) 15:18:24.83

>>662
めんどくさいので試してないんだよ。
試さなくても数学の用に読んで理解できる規則が欲しい。
Cのポインタは難しいとされるが、俺は数学が得意なので本を読んだだけで
完璧に理解できた。
C++探せばちゃんと書いてある本がある。

**デフォルトの名無しさん** · 2021/08/17(火) 15:23:08.50

>>661
BNFで書いてあるようだが、具体的にどこに書いてあるか示してくれ。
ちなみにBNFだと意味論までは語れ無い事があるので無理かも知れない。

**デフォルトの名無しさん** · 2021/08/17(火) 15:24:30.00

「俺は数学が得意なんだ！」
ワロタ
いつものBoxおじいさんじゃん

**デフォルトの名無しさん** · 2021/08/17(火) 15:24:31.45

目次を見てもReferenceの文字が見当たらないが。
C++だとちゃんとあるぞ。
どうしてReferenceも型のはずなのに、目次すらないんだよ。

**デフォルトの名無しさん** · 2021/08/17(火) 15:25:31.33

>>665
トップだったからな。

**デフォルトの名無しさん** · 2021/08/17(火) 15:27:48.00

>>660
そこまで言うならば十数種類あるRustドキュメントのうち、
editionとapiとstdとreferenceとtheとcookとexampleあたりにあとはcliとasyncくらいまでが基礎かな。
あと外部たがcargoとrustcにrustdocなどのbookも。
unstableやnomiconは後でいい。
wasmやembedded系bookも必要なら。

**デフォルトの名無しさん** · 2021/08/17(火) 15:28:18.82

IQ87の人でしょ
相手しちゃダメ

**デフォルトの名無しさん** · 2021/08/17(火) 15:29:44.40

>>668
なんで、この言語に置いて最も重要な型の一つの規則性がそんな何千ページもの
本を読まないと解説されてないんだよ。

**デフォルトの名無しさん** · 2021/08/17(火) 15:30:14.32

>>669
お前の友達と一緒にすんな。

**デフォルトの名無しさん** · 2021/08/17(火) 15:35:47.16

>>667
数学得意ならRustも深く理解しやすい
強い静的な型システムの元にある
そして生死貸借も明確で数学的にメモリ安全性を保証
利便性のための参照＆外し自動適用を除いて型キャストが暗黙に自動で行われることともない

**デフォルトの名無しさん** · 2021/08/17(火) 15:44:19.09

>>672
さっきから聞いているのに、ちゃんとした論理的規則を語った人は誰も居ない。
つまり、今このスレに居る人達は誰も理解してない証拠だろう。
つまりこれは、Rustが試してみないと分からない言語だからではないか。

**デフォルトの名無しさん** · 2021/08/17(火) 15:46:21.18

>>673
5chじゃなくて users.rust-lang.org あたりで聞いてみたら
専門家がいっぱいいるよ

**デフォルトの名無しさん** · 2021/08/17(火) 15:48:51.11

>>674
参照型はRustにとって最重要の型。
それがそんなところに質問しなければ分からないというのは困ったことだぞ。

**デフォルトの名無しさん** · 2021/08/17(火) 15:56:13.41

ポインタを理解するのにもRustを理解するのにも数学の得意不得意は関係なくね？

ポインタを理解できない人をあまり多く見たことがないから実際のところどうなのかよく分からないんだが

**デフォルトの名無しさん** · 2021/08/17(火) 15:57:56.00

>>670
どこにも記述されていないことを君が自己中心的な思い込みで間違いなく判断や間違った推測をしているから>>647や>>652の書き込みになっている
let文や呼び出し引数はirrefutable pattern matchingであり各種destruturingはあっても個々の型は対応する
Tと&Tがmatchingすることはない

**デフォルトの名無しさん** · 2021/08/17(火) 15:59:25.04

>>677
どから、それがどこに書いているのかリンクを張ってくれ。
あなたの独自説ではなく、公式のな。

**デフォルトの名無しさん** · 2021/08/17(火) 16:06:26.36

>>672
>利便性のための参照＆外し自動適用を除いて型キャストが暗黙に自動で行われることともない

rustではcoercionと呼んでるものが暗黙の型変換だぞ

**デフォルトの名無しさん** · 2021/08/17(火) 17:16:17.31

グリーンスレッド何それ？さんだっけ？

**デフォルトの名無しさん** · 2021/08/17(火) 17:20:32.19

公式の言葉が欲しいってならreferenceのlet statement, reference patternsあたりでもみりゃいいんじゃないっすかね知らんけど

**デフォルトの名無しさん** · 2021/08/17(火) 17:32:50.74

rustは思ったより流行りそうにないなぁ。
使用者爆発的に増えてくるハズがC++知らん人は
そもそも使う層じゃないし、
C++知ってる人は、逆にめんどくさいから様子見、流行らなければスルー
ぐらいかね。

**デフォルトの名無しさん** · 2021/08/17(火) 18:03:44.37

ぶっちゃけ1言語のみしか使えないようなプログラマが有能だとはとても思えないが
実際にそういう人はいるけど融通効かないし生産性が高いとも思えない
所詮ドカタじゃないの

**デフォルトの名無しさん** · 2021/08/17(火) 18:14:54.04

>>682
C++ で疲弊した人が Rust に移ってるってのはあるぞ。

**デフォルトの名無しさん** · 2021/08/17(火) 18:21:01.37

>>675
だからそう主張してくればよいじゃん
ここにいる人じゃ話にならないんでしょ？

**デフォルトの名無しさん** · 2021/08/17(火) 20:01:51.20

疲弊というかドロップアウター

**デフォルトの名無しさん** · 2021/08/17(火) 21:03:40.91

>>647
上３つの式は正しいのに、なんで下２つの式はそうなるのか

**デフォルトの名無しさん** · 2021/08/17(火) 21:04:44.45

>>687
見間違えた
一番下の式だけだね

**デフォルトの名無しさん** · 2021/08/17(火) 21:18:21.30

実際はc++わからんけどrustわかればマウント取れそうじゃね？って馬鹿しか手を出してないという現実。

**デフォルトの名無しさん** · 2021/08/17(火) 21:24:14.87

Rustは、GoogleTrendsでは他の言語に比べて低空飛行だけど(Kotlinと同じくらい
ではあるが)、他の言語が下がる傾向があるのに対してRustだけは少しずつ上がってる。
Stackoverflowでは既にC++の30%～40%位まで質問の量が迫ってきているとか。
なので良く分からない。
GoogleTrendsが実際と合ってないという説も見かけた。

**デフォルトの名無しさん** · 2021/08/17(火) 21:26:37.22

crates.ioでcrateをダウンロードされた回数が20億回を越えていたり、
投稿されたcrateの数が3万種類を超えたりとか。
20億回というのはとんでもない大きな数字。
全世界のプログラマの数は2,500万人くらいだそうだから相当な数だ。
良く分からないくらい異常に大きな数値。

**デフォルトの名無しさん** · 2021/08/17(火) 21:35:56.30

iocrateはきっと誰かがwhile true do; cargo build; cargo clean;doneみたいの流し続けたんだろ

c++よりマシなのは確かだがredosだかみたいの全然進まんしc++,cな代替物にはなれなさそう
tech giantsみたいな連中が根幹部分rustに変えるみたいな事言ってるけど流行ってる感じ全然しないよね(´・ω・｀)

**デフォルトの名無しさん** · 2021/08/17(火) 21:40:50.24

久しぶりに流行ってない流行らないアピールきてるね

**デフォルトの名無しさん** · 2021/08/17(火) 21:41:43.37

土方では流行らないでしょ

**デフォルトの名無しさん** · 2021/08/17(火) 21:45:28.03

リポジトリの分散化考えないとマジ負荷が半端無さそう

**デフォルトの名無しさん** · 2021/08/17(火) 21:49:53.88

rustで作ったライブラリは他の言語から使いやすいんかい？
c\c++置き換えるなら、むしろそここそ一番重要かもしれん。

**デフォルトの名無しさん** · 2021/08/17(火) 22:12:04.05

>>696
Rustのライブラリは他言語からは使いにくいのが問題になっていると聞いたが。
多分、C/C++のライブラリのようにはいかないと思う。

**デフォルトの名無しさん** · 2021/08/17(火) 22:14:00.60

>>692
前半、なるほど。
githubで最高人気であるところのvue.jsも、いいねは2万くらいだったと思うし。
なんか数値に異常さを感じる。

**デフォルトの名無しさん** · 2021/08/17(火) 22:16:21.15

vue.jsのgithubでのStar数は、18万7,000だった。
crate.ioのダウンロード回数はこの1万倍を越えている。
普通に使っているだけでは辻褄が合いそうに無いな。
全世界の全てのプログラマが100回くらいcrateをダウンロードしたことになる。

**デフォルトの名無しさん** · 2021/08/17(火) 22:54:36.64

crates.ioのDL数と比較すべきはnpmのDL数では？
https://www.npmtrends.com/vue

**デフォルトの名無しさん** · 2021/08/18(水) 00:15:56.99

crates.ioのダウンロード数は依存crateのCIが走る度に増えるようなものだからそりゃ多くなるでしょ
GitHubのstarと比較したのはなぜ？

**デフォルトの名無しさん** · 2021/08/18(水) 00:33:37.55

別にプログラマが手動でダウンロードするわけではないんだが…
1回コンパイルすると100個以上落としてくるのも普通だから
2千万回コンパイルが実行された、という程度の話
ざっくり5年で均せば1日1万回ってとこか

**デフォルトの名無しさん** · 2021/08/18(水) 01:06:03.53

CIだろうね。人がcargoを直に打ってるとは思えん

**デフォルトの名無しさん** · 2021/08/18(水) 01:16:27.76

強力にキャッシュが効くはずのCIでツールが未整備なために効かず
異常にDL数が伸びてしまっただけだろう

**デフォルトの名無しさん** · 2021/08/18(水) 04:35:06.87

CIのライブラリインストールが動画の次に無駄な帯域を食ってると言われているだけある

**デフォルトの名無しさん** · 2021/08/18(水) 09:18:01.26

>>639
難しく考えすぎ
&と*の関係は単純明白
let a = 123; // a: i32
let b = a; // b: i32
let p = &b; // p: &i32
let q = p; // q: &i32
let &r = &p; // r: &i32
let x = &q; // x: &&i32
let s = *x; // s: &i32
let c = *r; // c: i32
let y = &&c // y: &&i32
let z = y; // z: &&i32
let d = **z; // d: i32

**デフォルトの名無しさん** · 2021/08/18(水) 09:35:44.42

ライブラリが他言語から使いにくいってのも謎だな
他言語からならC ABI一択なわけで、どの言語でライブラリ書こうが使い勝手は同じだと思うが

**デフォルトの名無しさん** · 2021/08/18(水) 09:48:19.81

>>697
例えばPyO3でPythonからRust呼び出せるよ

**デフォルトの名無しさん** · 2021/08/18(水) 10:49:15.04

>>672
自動的な参照外し(*を記載してないのに*適用)って、値を使うところで&Tや&&Tなどが使われたときにTの値になる、というルールだからそれも数学的でしょ。
あと&Tではない各種スマートポインタや自作の型を、*記載で参照外しする時も、Derefトレイト実装通りに行われるからこれも数学的。

**デフォルトの名無しさん** · 2021/08/18(水) 11:27:15.93

>>647氏が混乱したのもそこかもね
例えば
let a = 99;
let b = &a;
assert_eq!(100, b + 1);
assert_eq!(100, *b + 1);
つまり値を使う所では参照のままではなく安全に*が自動適用

構造体のフィールドアクセスも
struct Point {x: i32, y: i32}
let p = Point {x: 19, y: 31};
let q = &p;
assert_eq!(p.x, q.x);
assert_eq!(p.y, (*q).y);
つまりフィールドアクセスする所では参照のままではなく安全に*が自動適用
だからC言語などにある「q->y」という記法がRustには不要なので存在しない

**デフォルトの名無しさん** · 2021/08/18(水) 11:41:08.71

こじつけの自己レス自演が気持ち悪い
これでバレないとおもってるんだからww

お前も頑張って勉強中なの丸出しなのになぜそんなに上から目線で書きたがる？

**デフォルトの名無しさん** · 2021/08/18(水) 12:12:05.22

>>710
assert_eq!(100, b + 1);　は通るけど
assert_eq!(99, b);　はコンパイルエラーになるところがミソかな

**デフォルトの名無しさん** · 2021/08/18(水) 12:12:56.84

演算子も含めてメソッド呼出しのときの self の参照が調整されるのは言語コアの機能だけど
演算子の右辺で参照が剥がされるのは参照を受け取るバージョンのメソッドも用意されてるから
という理解でいいんだよね？

**デフォルトの名無しさん** · 2021/08/18(水) 12:16:13.67

>>710
>assert_eq!(100, b + 1);

`b + 1`のbは*が自動適用されてるわけじゃない

**デフォルトの名無しさん** · 2021/08/18(水) 12:52:27.85

そこはstd::ops::Addトレイトのimplがあるかどうか
ただしi32と&i32に対してはあるけど&&i32に対してはない
そのためさきほどの例だと
let a = 99;
let c = &&a;
assert_eq!(100, **c + 1); // i32はそのままOK
assert_eq!(100, *c + 1); // &i32は参照外してi32でOK
assert_eq!(100, c + 1); // &&i32のAddトレイト定義はないからコンパイルエラー

**デフォルトの名無しさん** · 2021/08/18(水) 13:56:40.85

繰り返し間違った内容垂れ流すのいい加減やめれ

**デフォルトの名無しさん** · 2021/08/18(水) 14:02:16.47

>>715で合ってるよ

**デフォルトの名無しさん** · 2021/08/18(水) 14:42:37.07

ご愁傷様

**デフォルトの名無しさん** · 2021/08/18(水) 15:05:20.49

ご安全に*

**デフォルトの名無しさん** · 2021/08/18(水) 19:37:59.33

質問したようなのと近い流れになってて助かった

(0..7).filter(|&x| x == 0);
↑これ通るから　↓こうしたら駄目だった。なんでなん？
let mut vec0 = vec![1, 2, 3, 4, 5, 6];
vec0.iter().filter(|&x| x == 1);

そこで、様々テストしたら、↓の方法でコンパイルが通ることがわかった
どのやり方が一般的なん？個人的には1か4かと思うんだけど。あと、2は+0することで型推論が働いてるのん？
vec0.iter().filter(|&x| *x == 1); //1
vec0.iter().filter(|&x| x + 0 == 1); //2
vec0.iter().filter(|&x| x == &1); //3
vec0.iter().filter(|&x| x.clone() == 1); //4
vec0.iter().filter(|x| **x == 1); //5
vec0.iter().filter(|x| *x == &1); //6

**デフォルトの名無しさん** · 2021/08/18(水) 19:43:27.81

全部結果まで含めて正しかった？

**デフォルトの名無しさん** · 2021/08/18(水) 19:48:58.01

ベクタの内容を↓にして
let mut vec0 = vec![1, 2, 1, 4, 1, 6];
1の数をcountするようにして表示させてみたけど、>>720の1～6のやり方でどれもcountの数は同じだね

**デフォルトの名無しさん** · 2021/08/18(水) 20:01:07.37

いいぞ！いいぞ！これも通るぞ！！

let mut test6 = vec0.iter().filter(|&&x| x == 1).count();
let mut test7 = vec0.iter().filter(|x| x == &&1).count();
let mut test8 = vec0.iter().filter(|x| *x + 0 == 1).count();

ヽ(ﾟ∀ﾟ)メ(ﾟ∀ﾟ)メ(ﾟ∀ﾟ)ノ

**デフォルトの名無しさん** · 2021/08/18(水) 20:03:48.63

Bible終えるのにどれぐらい時間かかりましたか？

**デフォルトの名無しさん** · 2021/08/18(水) 20:30:38.07

>>720
(0..7).filter(|&x| x == 0);と同等なのは
let v = vec![1,2,3,4,5,6];
v.into_iter().filter(|&x| x==0);

**デフォルトの名無しさん** · 2021/08/18(水) 20:47:56.15

>>725
うおー、まじか！
わかったありがとう。だからforループはちょっと違う挙動になるんだな

**デフォルトの名無しさん** · 2021/08/18(水) 21:38:07.08

違いをわかりやすく示すと
let vec0 = vec![1, 2, 3, 4, 5, 6];
assert_eq!(Some(&1), vec0.iter().next());
assert_eq!(Some(1), vec0.into_iter().next());

**デフォルトの名無しさん** · 2021/08/18(水) 21:41:22.71

ありがとうありがとう
&TのイテレータとTのイテレータが別々になっているとはおもわなんだ

**デフォルトの名無しさん** · 2021/08/18(水) 21:54:22.03

まだ慣れてないからideに言われるがままに直してるな、、

**デフォルトの名無しさん** · 2021/08/18(水) 22:38:04.93

イテレータ回りはこのスライドが良いと思ったけど多少基礎知識ないときついかもしれんな
https://speakerdeck.com/optim/domination-of-the-rust-iterators

**デフォルトの名無しさん** · 2021/08/18(水) 23:13:44.45

>>728
そう考えるよりもムーブor借用と捉えるほうがいいかな
vec0.into_iter()だとムーブになるから値そのものが次々と来る。しかしその後にvec0は使えない。
vec0.iter()だと借用になるから値への参照が次々と来る。その後もvec0は使える。
(&vec0).into_iter()でも借用になるから値への参照が次々と来る。その後もvec0は使える。

**デフォルトの名無しさん** · 2021/08/19(木) 02:05:43.13

この2つは何が違うんですか？

演算子?
https://tourofrust.com/38_ja.html
unwrap
https://tourofrust.com/39_ja.html

**はちみつ餃子** ◆8X2XSCHEME · 2021/08/19(木) 02:52:20.85

>>732
これは例がよくないな。
もう一段ほど関数呼出しを挟む構造になっていればより分かり易くなる気がする。

? 演算子はエラーだったときにそのエラー値を返り値として return する。
つまりその例の場合は do_something_that_might_fail が
エラー値を返したときは main から抜ける。
関数がエラーを出したときに上位にもエラーとして伝播させる機能。

unwrap は Result を剥がすが、エラー値だったときにはその場で panic する。
unwrap を書くというのは「エラー値が返されることはないことをプログラマとして保証する」
または「そのエラーに対して対処する方法はない、対処する気はない」という表明で、
assert 的な意味合いを含む。
エラーの対処を書くのが面倒だけど Result を剥がして型は合わせないといけない
というときに雑に unwrap することはあるんだけど、
多少なりとも汎用的なライブラリにするなら (事前条件が正しい限り) panic が
起こるのは好ましくはないので使い方は慎重に。