Rust part20

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

公式
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 part19
https://mevius.5ch.net/test/read.cgi/tech/1673926892/

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

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

意味の有る無しを断じるあたり幼稚やな
周り見てご覧
キミ以外はそんなとこに拘っとらんやろ？

**デフォルトの名無しさん** · 2023/03/10(金) 19:36:05.08

>>141
そのあたりも本質の一つじゃね？
まあ俺なら>>130のif letにelse節がないことも問題視するけどな
そんな例ならif letを使うのがいいと自明だから問う価値がない
>>130がアホ

**デフォルトの名無しさん** · 2023/03/10(金) 19:40:18.95

好きな方使ってろバカども
前スレそれで使い潰してまだ反省してねえのか

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

>>130
前者は表明を表していて、後者は処理の条件を表している。
基本的に関数全体の条件を明示したほうが関数を使う側にとって使いやすいので、前者のほうが望ましい。

**デフォルトの名無しさん** · 2023/03/10(金) 21:43:27.35

現在のIT業界に「代替メモリレイアウト」という概念はありますか？

**130** · 2023/03/10(金) 22:22:59.62

>>130のコードは>>19のリンク先で「let-elseが便利すぎる」と銘打って紹介してたものなんだけど
let-elseを使う例としてはあまり適切な例ではないように感じたので他の人の意見を聞いてみたかった

理由はそれぞれ違うけどおおむね前者のほうがいいという意見が多くてスッキリした
ありがとう

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

>>142
少なくとも>>19のリンク先ではif let Someでelse節が必要ない状況だからこそ
let-elseを使うケースとして>>130の例を紹介している

**デフォルトの名無しさん** · 2023/03/10(金) 23:34:37.12

好きにしたらええ
それより前スレ埋めない？

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

>>145
「代替メモリレイアウト」という概念は聞いたことがないが悪魔の証明は無理なのでそういう概念がある可能性を完全に否定することはできない

非公式の日本語翻訳で使われてる用語みたいだけどこのスレで質問する際は公式のドキュメント(英語)を参照するようにしてね

**デフォルトの名無しさん** · 2023/03/10(金) 23:54:51.68

if letを使うかlet elseを使うかはケースバイケースでどちらもありうるのだから揉めるようなことではないと思うんだよな
let elseは要らないから削除せよ！と言ってた人はここを荒らすためだけに言ってただけだと思うし

**デフォルトの名無しさん** · 2023/03/11(土) 00:35:13.78

>>150
ケースバイケースだからこそ具体的な特定のケースを例にどちらがいいかを話してるんだろ

**デフォルトの名無しさん** · 2023/03/11(土) 00:54:45.06

Rust標準ライブラリのソースを見るとよくわかるよ
let else構文はもちろん使われまくっている
可読性が良くなるからね

**デフォルトの名無しさん** · 2023/03/11(土) 06:31:08.87

インストールでつまずいたのでチラ裏させてくれ
サンプルプログラムをコンパイルしたら`link.exe` not foundでコンパイルできなかった。
原因は、Build Tools for Visual Studio 2022をインストールしてしまったこと、アンインストールして
Build Tools for Visual Studio 2019をインストールしてコンパイルできた。

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

相も変わらず1人だけズレてるな

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

>>152
ネストが深くならないように積極的にlet else使うのが良いみたいやな
130の例はネストが無いことがif letのままでいい根本的な理由となるわけだ

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

let-elseはパターンに合致しないと処理を継続できない場合に早期離脱（return、break、etc.）するための構文でしょ
それ以外でも使えるだろうけど逆に可読性が落ちそう

従来の言語で

if (nullable_obj == null) { continue; } // この行を書き忘れるとえらいことになる
nullable_obj.do_something();
...

みたいに書ける処理を今までのRustだと

if let Some(obj) = nullable_obj {
　obj.do_something();
　...
} else { // ループの末尾ならここは不要
　continue;
}

か無理やりunwrapして

if nullable_obj.is_none() { continue; } // この行を書き忘れるとえらいことになる
let obj = nullable_obj.unwrap();
obj.do_something();
...

みたいに書くしかなかったけど、let-elseを使うと従来の言語に近い形で書けるようになる

let Some(obj) = nullable_obj else { continue; }; // この行を書き忘れることはできない
obj.do_something();
...
returnだと?演算子で十分な場合もあるだろうから敢えてcontinueにした

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

let elseはcontinueでもbreakでもreturnでもpanicでも!なら何でも使えるし使われている
returnの時にErr返しなら?を使ってもよいが
.ok_or_else(|| Error)?; とするか
elseでreturnするか
どちらが見やすいかは意見が別れそうだ

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

Rustに限った話ではないがリファクタリングの良し悪しを判断するためには該当箇所を含む関数の全容(特に関数シグニチャ)とその関数を呼び出すコード例が最低限必要
関数シグニチャも呼び出すコードもない例では話にならない

呼び出し側が絶対変更できない前提なら前者だけでもいい場合があるが往々にして部分最適になりがち
>>130の例でも呼び出す側を考慮するとまた違った選択肢が見えてくる

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

コーディング規約で早期リターンが推奨される開発現場であれば
その規約に準拠した表現が書きやすくなったのは良いこと
つうかそのつもりで読んでたから後者のほうが読みやすかったわ

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

>>158
?とOptionとResultの影響があるから
他の言語よりも関数シグニチャーの持つ意味が余計に大きいように思う

**デフォルトの名無しさん** · 2023/03/11(土) 14:09:20.55

隔離スレでやれ

**デフォルトの名無しさん** · 2023/03/11(土) 20:53:29.08

https://qiita.com/namn1125/items/ccedf9cc06b8cef71557#let-else文のユースケース
この人が書いてるように?演算子のイディオムを踏襲してればlet-elseの出番は多くはない
逆に本来使うべきでないところでも乱用されやすいから注意が必要

**デフォルトの名無しさん** · 2023/03/11(土) 23:05:55.56

>>159
多くのところで言語に関わらずでifネストを深くせずに早期離脱をすることが好まれる
Rustではif let時にそれができなかったためlet else導入まではこうなってしまっていた
let foo = if let Some(foo) {
　foo
} else {
　(早期離脱前の処理があればここ)
　早期離脱
}
これはfooが三重に冗長で不格好
そのためlet else以前は早期離脱をあきらめる本末転倒なことも起きていた

具体的にlet elseが適している早期離脱は「範囲」が広い
・break
・continue
・エラー以外のreturn
・早期離脱前の処理があるエラーreturn

>>162
？が使える「範囲」はlet else より狭く早期離脱前の処理がないエラーreturnのみ
もちろん「量」は多いけどね

**デフォルトの名無しさん** · 2023/03/12(日) 11:57:58.73

カルパッチョ

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

初見

VS code使い始めたんだが、カーソル移動系のショートカットキーの編集ってできないのか?
さくらEditorみたいにカーソル移動・ドラッグ編集を全部キーボードでやりたいんだが

**デフォルトの名無しさん** · 2023/03/12(日) 12:42:40.81

なぜここできく

**デフォルトの名無しさん** · 2023/03/12(日) 14:07:53.88

File > Preferences > Keyboard Shortcutsで設定画面開いて
cursorでフィルターかければcursorLeftみたいなコマンド出てくるから大体は変更できると思う
知らんけど

**デフォルトの名無しさん** · 2023/03/12(日) 14:14:14.53

vimでもemacsでもrust-analyzer動くよ

**デフォルトの名無しさん** · 2023/03/12(日) 15:10:27.15

>>166
プログラム板で一番勢いあるのここだから

**デフォルトの名無しさん** · 2023/03/12(日) 16:06:30.84

大学生が書いたQiita記事のほうがこのスレの住民より要点おさえてるじゃんw
おまえらも見習えよ

**デフォルトの名無しさん** · 2023/03/13(月) 11:54:44.62

Qiitaは秀才だらけだし
5chム板は文字通り住民がrustだし

**デフォルトの名無しさん** · 2023/03/16(木) 07:24:49.76

>>162
その記事を読んでみたが漏れもあり
>>163のまとめで十分と思った

**デフォルトの名無しさん** · 2023/03/16(木) 10:05:31.80

複オジにいちいち突っ込むのは疲れたよ
>>163見れば素人だとすぐわかる
もう騙される人もいないから注意する必要もない

**デフォルトの名無しさん** · 2023/03/16(木) 10:12:16.89

具体的に何が問題なの？

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

>>174
いつもの自演だろ。
真面目な話題はワッチョイスレにしようぜ。

**デフォルトの名無しさん** · 2023/03/16(木) 18:54:09.77

オジおじ言ってたら自演
スレ荒らしが目的

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

こういうコードを書くとエラーになります。
Bar を実装しているのは &T であって T ではないからだというのはわかるのですが、
どういう形で書けばいいのかわかりません。
T そのものではなく &T が Bar を実装しているという制約はどう表現すればよいのでしょうか？

trait Bar {
fn func(&self) {}
}

fn baz<T>(x: &T)
where
T: Bar, // どう書けばいいの？
{
let a = x.func();
}

struct Foo {}
impl Bar for &Foo {}

fn main() {
baz(&Foo {});
}

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

>>177
✕ impl Bar for &Foo {}
○ impl Bar for Foo {}

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

>>178
それは変えられない前提の部分です。
制約の付け方 (where句の書き方) を質問しています。

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

どうしてもimpl Bar for &Foo {}で行きたいなら
こうするしかない

trait Bar: Sized {
fn func(self) {}
}
fn baz<T>(x: T) where T: Bar,

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

いやできるが……
fn baz<'a, T>(x: &'a T) where &'a T: Bar

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

なるほど、寿命を省略できないのですね。
ありがとうございます。

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

>>182
Rustコンパイラからのエラーメッセージを見てる？
参照に対してライフタイム付けろと出ているはず

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

寿命！

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

>>183
答えを見たら全く自然なことだということは理解できるんですが
explicit lifetime というのがなんのことかすらぴんと来ない程度なんです……。

**デフォルトの名無しさん** · 2023/03/18(土) 11:19:09.17

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

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

>>186
>>177て”公式”のThe Bookに書いてあったっけ？

**デフォルトの名無しさん** · 2023/03/18(土) 11:42:47.58

lifetime 周りは書いてあるだろ

**デフォルトの名無しさん** · 2023/03/18(土) 11:53:17.34

>>188
>>181とかどこだっけ？

**デフォルトの名無しさん** · 2023/03/18(土) 11:57:09.36

>>185
ライフタイムは全てにあるが省略できることが多い
省略できないときはコンパイラがエラーとし教えてくれるのでライフタイムを付ければいい

>>186
日本語版もある
https://doc.rust-jp.rs/book-ja/

**デフォルトの名無しさん** · 2023/03/18(土) 14:05:24.60

>>190
誤訳だらけの粗悪な非公式日本語訳はお勧めしない
簡単なエラーメッセージの意味も分からないような状態なんだからまずは公式The Bookをしっかり読むべき

**デフォルトの名無しさん** · 2023/03/18(土) 16:08:20.29

「非公式な日本語訳」を「日本語版」と呼称するのはそれがあたかも公式かのように錯覚させる意図が見えるので優良誤認の疑いがある

**デフォルトの名無しさん** · 2023/03/18(土) 16:13:56.89

>>187
The Bookはクックブックじゃないからな
特定の方法が書いてるか書いてないかよりも
読んで理解してれば自己解決できる問題かどうかが重要

**デフォルトの名無しさん** · 2023/03/18(土) 17:11:12.32

日本語訳の話題は生産的じゃないのでやめよう
このスレのローカルルールは>>37の通り

**177** · 2023/03/18(土) 18:27:39.58

読んだのは日本語訳のほうの The book ですが、個々の機能はたぶん分かってると思います。
ライフタイムを省略した場合には一定のルールで補われることも知ってました。
ただ、型が満たすべき性質を書くのが where 句なので (エラーメッセージを見てすら！) ライフタイムが必要ということがぴんと来なかったというのと、
引数と同じ記法でライフタイムをここに書けるのだということがわからなかったんです。

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

> 引数と同じ記法でライフタイムをここに書けるのだということがわからなかったんです。
英語版でも日本語版でもどっちでもいいけど 10.3 にちゃんと書いてあるよ

**デフォルトの名無しさん** · 2023/03/18(土) 19:09:39.09

whereの:の左辺に参照とか書けるのをまず知らなかったんでしょ
the Bookにそんな例無いし

**デフォルトの名無しさん** · 2023/03/18(土) 19:27:58.81

日本語版を読まなければこんなことにはならなかった
日本語版を許すな

**デフォルトの名無しさん** · 2023/03/19(日) 04:14:30.76

>>183
ラストコンパイラって響きカッコいいな

**デフォルトの名無しさん** · 2023/03/19(日) 13:06:57.80

>>193
この場合に必要なのはクックブックだろ。
せめて>>196みたいに誘導しないと。

「読んで理解すれば自己解決できる」とか、そもそも読むところも示していないのにできるわけない。読み手を無視してマウントする自慰行為にしか見えん。

**デフォルトの名無しさん** · 2023/03/19(日) 13:09:44.94

そりゃ「個々の機能はたぶん分かってると思います」とか言われたら分かってねーじゃんって言いたくなるだろ

**デフォルトの名無しさん** · 2023/03/19(日) 13:23:44.49

>>196
where 句の制約で書いてる事例はないよ。

**デフォルトの名無しさん** · 2023/03/19(日) 14:19:01.09

>>200
訳の分からない日本語訳読んでわかったつもりになってるだけだからそう感じるんだよ
つべこべ言わずに全部読め

**デフォルトの名無しさん** · 2023/03/19(日) 14:25:09.74

>>202
grepだけじゃ答えは見つからない
読んでないから調べ方もわからない

**デフォルトの名無しさん** · 2023/03/19(日) 20:29:29.27

>>203
順調に日本Rustは錆びているようですね。いや、めでたい。

**デフォルトの名無しさん** · 2023/03/19(日) 20:49:16.05

ちゃんとあるじゃん
https://doc.rust-jp.rs/book-ja/ch10-03-lifetime-syntax.html#%E3%83%A9%E3%82%A4%E3%83%95%E3%82%BF%E3%82%A4%E3%83%A0%E6%B3%A8%E9%87%88%E8%A8%98%E6%B3%95

**デフォルトの名無しさん** · 2023/03/19(日) 21:36:02.67

Rustはベンチマーク速いから気になってるんだけど
iPhoneやAndroidの開発で将来的に使えるようになる話はないの？

**デフォルトの名無しさん** · 2023/03/19(日) 21:40:34.06

ゴミだな

**デフォルトの名無しさん** · 2023/03/19(日) 21:41:36.36

>>207
普通に使えるやろ

**デフォルトの名無しさん** · 2023/03/19(日) 21:48:03.22

>>177見て思うんだじぇど
ゆとり教育超大国日本ではゆとり脳な奴が多数になって
エラーがでたよ、でも、エラー内容は書かないようなコミュ力の低い奴が
普通になっているんかな。

**デフォルトの名無しさん** · 2023/03/19(日) 22:05:41.03

>>210
いくつか落ち度はあっても>>177は自分の考える最小限の再現可能なコードを提示してるからめっちゃくちゃマシな質問者
質問者としての偏差値63くらい

**デフォルトの名無しさん** · 2023/03/19(日) 22:08:47.66

5chでの偏差値ね
Stackoverflowだと47くらい

**デフォルトの名無しさん** · 2023/03/19(日) 22:25:46.74

>>207
ネイティブコンポーネントには Rust は使える。
Android の根本設計が Linux+JVM で、 JVM は変に高級な設計だからその高級な機能に噛み合うように設計された言語じゃないとうまくいかない。
LLVM バックエンドで JVM バイトコードを生成するものもあるらしいから無理すりゃ Rust でもなんとかなるかもしれないけど……
それよりも現在の情勢を見ると Android に WASM サブシステムが入るとかのほうがあり得そうな気がするよ。

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

自然言語自体に落ち度があると思った方がプログラミング言語の価値が分かりやすい
翻訳にも質問にもChatGPTにも過度の期待をしなくてすむ

**デフォルトの名無しさん** · 2023/03/20(月) 01:31:12.77

言語の問題と言語を扱うやつの問題を同一視するアホ

**デフォルトの名無しさん** · 2023/03/20(月) 01:42:28.65

正常動作する正規品を期待してたのに
不具合だらけで役に立たないジャンク品でした

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

はした金ではジャンク品しか買えない
インフレか
物価の問題と品質の問題のような二つの問題を無関係と考えるのがアホだったんじゃないか？

**デフォルトの名無しさん** · 2023/03/20(月) 03:09:08.81

prettierの代替のdprintがRust製だった
普及してるものがRust製に置き換わるってが今後も続くだろうね

**デフォルトの名無しさん** · 2023/03/20(月) 03:46:46.02

>>217
ところが実際はジャンク品のほうが正規品より高いんだなこれが
正規品に見せかけて売ってるからいわゆるジャンク扱いではなく蓋を開けたらゴミでしたという落ち

でもありがたいことに今は購入前に中身を確認可能なのでよほどの情弱じゃなければ騙されないんだけどね

**デフォルトの名無しさん** · 2023/03/20(月) 10:04:17.69

>>217
物価の意味も知らんのかww
恥ずかしいから辞書引けよ

**デフォルトの名無しさん** · 2023/03/20(月) 10:58:26.51

このあたりを読んでおけば大丈夫
Advanced Lifetimes
https://doc.rust-lang.org/1.30.0/book/second-edition/ch19-02-advanced-lifetimes.html

**デフォルトの名無しさん** · 2023/03/20(月) 11:08:21.33

>JVM は変に高級な設計だからその高級な機能に噛み合うように設計された言語じゃないとうまくいかない。

相変わらずいい加減なこと書いてるなぁ

**デフォルトの名無しさん** · 2023/03/20(月) 11:41:00.74

アプリもコンパイラも動くLinuxが正規品
コンパイラは不要とされアプリしか動かないLinuxがジャンク

**デフォルトの名無しさん** · 2023/03/20(月) 11:59:59.11

>>223
GNUにケンカ売る気かよ

**デフォルトの名無しさん** · 2023/03/20(月) 14:23:43.87

**デフォルトの名無しさん** · 2023/03/20(月) 17:14:18.78

flattenとかflat_mapとかfilter_mapとか

**デフォルトの名無しさん** · 2023/03/20(月) 19:58:13.92

flat_mapはmap(f).flatten()の順だから無理だな
filter_mapはOption外しに使えるがmap(f)は別途必要
filter_map(|opt| opt).map(f)　または参照なら
filter_map(Option::as_ref).map(f)
したがって正解はこれ
flatten().map(f)

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

flattenのOption/Resultはずし知らんかった

**デフォルトの名無しさん** · 2023/03/20(月) 20:32:22.28

>>227
どれでもできるぞ
初手で一番素直な選択はfilter_map

**デフォルトの名無しさん** · 2023/03/20(月) 20:46:14.12

flattenを使ってできました
let v = vec![None, Some((1, 2)), None, Some((3, 4)), None];
assert_eq!(14, v.iter().flatten().map(|(a, b)| a * b).sum());

>>229
filter_mapを使うと簡単ならば知りたいです

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

複オジかよっw

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

前述したようにfilter_map自体のmapではOption外ししかできないので別途map(f)が必要になる
filter_map(|opt| opt).map(f)
あるいは
filter_map(|opt| opt.map(f))
簡単なのはflatten().map(f)

**デフォルトの名無しさん** · 2023/03/20(月) 23:15:03.64

flat_mapはfilter_mapを汎用化したものなので
filter_mapは常にflat_mapで書き直せる
flattenと理屈は同じ

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

唐突に妙に具体的な質問が飛んできたらあの人だと思ってればいい

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

どの人だよ

**デフォルトの名無しさん** · 2023/03/20(月) 23:49:46.77

>>234
いやー俺は今回まんまと騙されたわ
自演力と自画自賛力にステ振りすぎとちゃう？

**デフォルトの名無しさん** · 2023/03/21(火) 00:12:49.49

>>226 >>233
質問はOption列が対象のようだからflat_mapとfilter_mapは対象外やろ
それらはむしろOptionを作る関数を与えて使う
元から既にOptionになってるのだからflattenが正解

**デフォルトの名無しさん** · 2023/03/21(火) 10:42:06.27

Someだけ拾って関数をmapすると考えれば
filter_map(|opt| opt.map(f))
だな
元のSome/Noneをそのまま利用するのがトリッキーかもしれないけど

**デフォルトの名無しさん** · 2023/03/21(火) 11:33:54.48

ところで、ラムダには自由変数というものがありその反対が束縛変数だが
ラムダや自由変数を意識する必要がない文脈で束縛という用語が出ると
その語源を説明する手間がかかるよな

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

scalaやっているせいかmatchとか
すごく使いやすいわん
iterator nextなんてJavaでも使わんけど
これ使い人いるの？

**デフォルトの名無しさん** · 2023/03/21(火) 13:17:10.53

>>240
nextはIterator全ての基礎
nextだけを定義すれば他のメソッドはnextで作られているので自動的に定義される
for文もnextを使っている