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/01/17(火) 12:41:51.84

たておつ

**デフォルトの名無しさん** · 2023/01/17(火) 14:00:56.91

89 それでも動く名無し 2023/01/10(火) 23:26:51.53 ID:pA5+SQtP0
痴漢ものAVと違ってこういうガチ痴漢は臨場感が違うわ
抵抗されて上手く行かなかったり、たまに他の客にバレて逃走してるからな
マジで興奮する
https://i.imgur.com/My4nuB1.jpg
https://i.imgur.com/ttXkWGH.jpg
https://i.imgur.com/upphmaU.jpg
https://gcol;le.net/product_info.php/products_id/763929/ref/15062/affiliate_banner_id/1

520 名無しさん＠ピンキー sage 2023/01/03(火) 21:36:57.85 ID:AS4vmq4R0
不朽の名作が復活していたので
https://i.imgur.com/SGsDTp5.jpg
https://i.imgur.com/4R20ojB.jpg
https://gcol;le.net/product_info.php/products_id/863650/ref/15062/affiliate_banner_id/1

**デフォルトの名無しさん** · 2023/01/17(火) 14:01:08.20

すみません、誤爆しました

**デフォルトの名無しさん** · 2023/01/17(火) 14:04:39.15

　　　. :::';;;;: . .　　　　　..,,,;;:
　　 . . :;;;;;:.:;;,,　　　　..:.;;;;.:
　　 :;;'''　　.:';;; . .　 .:.:;;;;;':. . .　　　　　　　.,,,,;,,...,,
　　　　　　.:;;;' :　　.:;;;;; .: ,,,;;;,,,　　 ,　 .:;;;';;'''　''';;;;,,
　　　　 . :.;;;;' . .: 　　;;;;;;;;''''　';;;:.:.. ,;: . .　　　　''''''"
　　　　　';;:;'　　　　　'''';　　 .:.';;;;,,;;.
　　　　　　　　　　　　　　　　　'''　 ,.:.:';;;;,,,,
　　　　　　　　　 ,､—-､　　　 .;.';:;.:.: ;;;;;;:.;.;...
　　　-､_ 　　　　　（＿二ﾆ=っ,､;;;:.:;.:;...:.:...'''''''''''
　　　　　`‐-､_　　（　　´∀）f、　`''､:..:.:. .:
　　　　　　　　 `-,ﾉ　　　つ; /
　　　　　　　　　（〇　　〈-`'"
　　　　　　　　　(＿,ゝ　）　`‐-､_
　　　　　　　　　　　（＿_）　　　　 `'‐-､,_..
　　　　　　　　　　　　　　　　　　　　　　 `‐-､._

**デフォルトの名無しさん** · 2023/01/17(火) 14:25:12.33

ここが新しいおちんぽスレと聞いて

**デフォルトの名無しさん** · 2023/01/17(火) 14:31:29.73

最低だな
犯罪者予備軍やん

**デフォルトの名無しさん** · 2023/01/17(火) 16:35:46.70

通報しといたよ

**デフォルトの名無しさん** · 2023/01/17(火) 16:41:04.96

はよ立て直せ

**デフォルトの名無しさん** · 2023/01/18(水) 10:59:16.69

ワッチョイ有効スレ
https://mevius.5ch.net/test/read.cgi/tech/1674007100/

**デフォルトの名無しさん** · 2023/01/18(水) 12:30:23.66

おちんぽまんまんスレ違いと聞いて

**デフォルトの名無しさん** · 2023/01/18(水) 20:15:50.70

ResultがErrの時だけブロックを実行するifってどうやって書けばいいの？
if Err(_) = fs::read_to_string("foo.txt") { err() }
は通らないようだが

**デフォルトの名無しさん** · 2023/01/18(水) 20:29:34.91

if let Err(_)

**デフォルトの名無しさん** · 2023/01/18(水) 20:41:58.72

>>13
サンキュー。行けた

**デフォルトの名無しさん** · 2023/01/19(木) 04:27:00.05

>>12
エラーが起きた時は先に判断してreturnして
そうでなく正常値が得られた時はlet代入してインデントを下げずに書けないかな？

**デフォルトの名無しさん** · 2023/01/19(木) 07:51:52.20

>>15
それが少し前に入ってみんな喜んでた let else だね。

let Ok(value) = result else { return };
/* Ok のときやりたい処理 */

みたいにエラーは早期リターンして、正常系をインデント下げて書くみたいなことができる。

俺は Err は anyhow で呼び出し側に返しちゃう事が多いから正直あまり使わないけど。

**デフォルトの名無しさん** · 2023/01/19(木) 10:36:41.67

Option/Result系は?演算子で素直に返すしそれ以外でもResultを返す関数に切り出して呼び出し側で?演算子にするからlet-elseは使い所がよく分からん

**デフォルトの名無しさん** · 2023/01/19(木) 11:05:24.00

>>15
そもそもreturnしない。err()の中身はエラーメッセージを出力後にパニックさせるので一方通行

**デフォルトの名無しさん** · 2023/01/19(木) 13:52:46.10

expectじゃだめなのかな？
もう少しちゃんとしたロギングをしたいならlog crate使ってlog_expectみたいな形でunwrap

**デフォルトの名無しさん** · 2023/01/19(木) 14:21:48.46

自分で書いといてあれだからやっばりexpect使うケースじゃないな
panicさせるよりもErrのまま最上位まで返してそこでログ出力含めてハンドリング

**デフォルトの名無しさん** · 2023/01/19(木) 18:44:58.53

expectってライブラリの動作確認とかサンプルコードとか、トップレベルで雑なことしたいとき以外使わなくない？

深めの階層で見かけたら身構えちゃいそう。

**デフォルトの名無しさん** · 2023/01/19(木) 19:25:25.54

論理的に安全にunwrapできるってわかってる箇所には使うかな
もしパニックになるならそもそも致命的な論理バグがあるってことになるから
変にエラー処理するより早期に落とした方がいいってケース

**デフォルトの名無しさん** · 2023/01/19(木) 20:03:32.07

横からですまんが安全なら unwrap() でよくない？
expect() にする理由ってなんだろう

**デフォルトの名無しさん** · 2023/01/19(木) 20:30:48.24

個人的には Regex::new(r"").unwrap() みたいに自明ならunwrap
安全にunwrapできる理由を書きたいならコメントに書くよりexpectに書くかな

**デフォルトの名無しさん** · 2023/01/19(木) 20:45:59.09

なるほどね。自明な時に unwrap したいけど、仮に起きたときに原因調査しやすいよう expect というのは納得できる。

**デフォルトの名無しさん** · 2023/01/19(木) 20:51:26.80

あ、違うか。unwrapできる理由を書くわけか。

paniced at 'ここでは 0 は渡ってこないので自信を持って除算する'

みたいな出力になるから割と恥ずかしいな。

**デフォルトの名無しさん** · 2023/01/19(木) 21:03:13.60

>>26
これは俺も思ったｗ
まぁ自分しか使わないライブラリとかならいいかもね

**はちみつ餃子** ◆8X2XSCHEME · 2023/01/19(木) 22:24:19.09

>>27
自分意外が使う前提のときのほうが except が必要だと思う。

外部から与えられる情報が仕様外の場合 (事前条件が満たされない場合) など
使い方が誤っているときに起こりえるなら except で説明があったほうがいいんじゃない？

内部的なロジック的に起こりえないと確信しているところは unwrap でいいと思う。
間違いがあったときに panic! してくれることには変わりないしバックトレースも出せるんで、
特に必要だと思う箇所だけ説明を付けておけば十分でしょ。

**デフォルトの名無しさん** · 2023/01/19(木) 22:58:51.51

>>26
関係ないけどpanicに-ed、-ingつけるとkが差し込まれてpanicked、panickingになる
自分もRust触るまで知らなかった

**デフォルトの名無しさん** · 2023/01/20(金) 00:14:17.87

Optionを返す関数が2つ(以上)あり、
Someを得られるまで遅延評価で順に試す場合に、
func1(arg)
.or_else(|| func2(arg))
と非対称で手間なのを改善する方法ありますか？
例えば　func1(arg) || func2(arg)　と書けると便利だと思いました

**デフォルトの名無しさん** · 2023/01/20(金) 00:47:21.47

イテレータ化してchain()で繋げるとか？
でも手間は変わらないか

**デフォルトの名無しさん** · 2023/01/20(金) 02:52:18.79

>>30
ないんじゃね
何回も書く必要があるなら単に関数化する
||演算子で書きたければマクロ内独自文法作る

**デフォルトの名無しさん** · 2023/01/20(金) 11:05:21.77

>>20
今だいたいそうなっていてmainにエラー出力用のコードが散在している状態
エラーメッセージの出力先もコンソールのみじゃないのでexpectだと難しい気が

**デフォルトの名無しさん** · 2023/01/20(金) 13:36:20.52

ちんちん！シュッ！シュッ！!シュッ！!!

**デフォルトの名無しさん** · 2023/01/20(金) 21:59:08.95

>>33
いろんな問題をごちゃ混ぜにしすぎ
頭とコードを整理しよう

**デフォルトの名無しさん** · 2023/01/21(土) 14:16:15.90

１．すべてmainまで返してmainでエラー処理をする
２．エラー処理用の関数を作ってそれを呼び出す
３．パニックハンドラでエラーメッセージを出力
くらいしか思いつかん。ググってもThe Bookに書いてある程度のことしか出てこなくて参考にならない
３はpanic!やexpectで脱出できるのは楽だけどハンドラへ渡せるデータが文字列のみでなのがいまいち
またエラー処理に必要な情報を文字列にエンコードする必要がある
２ならmainまで戻らずともエラー処理できるのでこの方向で実装中

**デフォルトの名無しさん** · 2023/01/21(土) 14:57:31.49

log crateやtrace crateはチェック済み？
logは準標準、実装は好きなのを選ぶ必要がある
traceはtokio-rs製

**デフォルトの名無しさん** · 2023/01/21(土) 16:41:16.71

>>32
|オペレータのstd::ops::BitOrトレイトのように
||オペレータのトレイトをRustコンパイラが用意してくれたらOptionも||で扱えそう

**デフォルトの名無しさん** · 2023/01/21(土) 18:30:23.18

>>37
info!やerror!ってpanic!やexpectと本質的に変わらないような。いずれにしろ呼び出し側で文字列の加工が必要
GUIへの対応方法もよくわからない。開発時はもちろんコンソールへの出力を使うけど
運用中のエラー出力はGUIのポップアップメッセージがメインになるし

あとソースコードは600行弱くらいだけどリリースビルドで生成されるバイナリは800KB弱もあるんで
これ以上でかくしたくないというのもある

**デフォルトの名無しさん** · 2023/01/21(土) 22:40:10.67

ロガーを設定/生成するコード
ロガーを使うコード
ロガー自体のコード
それぞれ分けて考える

ロガーを使うコードではファイル出力だろうが標準出力だろうがinfo!やerror!でコードを変える必要はない
使うロガーを変えたり設定を変えたりする

ロギングライブラリを使うのは自前で作るのは面倒だから

**デフォルトの名無しさん** · 2023/01/22(日) 02:33:12.00

書籍で最初に読むとしたら
平家蟹の方？
それとも可愛い方？

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

平家蟹がかわいくないとか、こいつアンチか？

**デフォルトの名無しさん** · 2023/01/22(日) 02:46:40.77

>>39
>GUIへの対応方法もよくわからない。
GUIのレイヤーまでResultを戻してErrならエラー表示をするだけ

**デフォルトの名無しさん** · 2023/01/22(日) 12:43:00.06

>>39
ログはログ。何が起きたか記録するだけ。ログレベルが何であれ副作用は起こさない。
エラーはエラー。発生したときにどうハンドリングするかはプログラムの性質で決める。
パニックはそのまま稼働したらまずい状況に陥ったら時だけ起こす。

**デフォルトの名無しさん** · 2023/01/22(日) 14:52:04.22

>>41
モンタギュー蟹の方

**デフォルトの名無しさん** · 2023/01/22(日) 15:29:33.81

アプリケーションのレイヤーでパニック起こすのはバグの時だけ

**デフォルトの名無しさん** · 2023/01/25(水) 16:19:44.22

ネットワーク前提にしてる時に、panicになるのはバグではないよ？

**デフォルトの名無しさん** · 2023/01/25(水) 16:35:00.31

うっわすっげー読みやすいコードと思ってよく見てみたら
過去に自分が書いたやつだった(´･ω･｀)

**デフォルトの名無しさん** · 2023/01/25(水) 16:39:27.19

天才か？

**デフォルトの名無しさん** · 2023/01/25(水) 16:40:49.73

過去の自分は他人だと思え、がプログラミングの基本

**デフォルトの名無しさん** · 2023/01/25(水) 17:17:39.71

過去のことを忘れていても過去の自分が考えることは今の自分が考えることとあまり差がない。
名前の付け方とかは何度考えても同じような状況なら同じ名前を付けるし。

書くときに想定する読み手が全くの他人のときと未来の自分のときではちょっと違う意識があるな。

**デフォルトの名無しさん** · 2023/01/25(水) 18:36:03.64

一度も使ったことがない機能は書くことはできても読めると思うな、が基本
使ってから読め

**デフォルトの名無しさん** · 2023/01/25(水) 19:53:08.97

>>47
ネットワークこそ途中で途切れること前提に書かないといけない機能の最たるものだろ。エラー返してハンドリングしろ。

**デフォルトの名無しさん** · 2023/01/25(水) 20:37:11.28

>>48
あるあるだね

**デフォルトの名無しさん** · 2023/01/25(水) 20:38:19.94

>>47
なんでpanicになるの？

**デフォルトの名無しさん** · 2023/01/25(水) 21:43:02.36

>>38
一度ポシャってるけど実装される可能性はあると思う
https://github.com/rust-lang/libs-team/issues/144

**デフォルトの名無しさん** · 2023/01/25(水) 23:55:49.39

bool以外でも&&と||の遅延評価が使えるようになるわけか
欲しいね

**デフォルトの名無しさん** · 2023/01/26(木) 00:47:59.28

bool以外でもifを使えるといえばif letで
elseを省略することで3項ではなく2項演算のようになるのも&&と同じ
だがelseを省略できても{}を省略できなければ意味がない

**デフォルトの名無しさん** · 2023/01/26(木) 11:05:43.50

>>58
もうちょっと基礎を勉強してからレスしろ

**デフォルトの名無しさん** · 2023/01/26(木) 11:09:10.89

すまんが、これの解答はmutをつけろっていうことなのはわかるけどさ
https://github.com/rust-lang/rustlings/blob/main/exercises/variables/variables4.rs
なんで8行目で所有権を失って9行目で代入できなくなったりしないの・・・・？

**デフォルトの名無しさん** · 2023/01/26(木) 11:24:13.84

>>60
これはもっともな疑問

The Bookのどこかに書いてたように思うけど
ざっくり言えばprintlnはreferenceを取るから所有権は移動しない

DisplayトレイトやDebugトレイトのメソッドシグニチャを見ると分かる

**デフォルトの名無しさん** · 2023/01/26(木) 11:33:53.75

>>60
ついこないだ Teratail で同じような質問を見たぞ。
マクロは構文糖を作り出す仕組みなので展開形によっては所有権を取ることも借用なことも何にも使いすらしないということもある。

**デフォルトの名無しさん** · 2023/01/26(木) 14:03:27.91

ある関数の&mut T型の引数として、T型の変数を貸すのは分かるけど
&mut T型の変数を又貸しするのが不思議
なぜmoveしたことにならないのか

**デフォルトの名無しさん** · 2023/01/26(木) 15:25:17.84

>>63
&TはCopyだからmoveしないよ

**デフォルトの名無しさん** · 2023/01/26(木) 15:35:28.34

>>63
implicit reborrowのことかな？
&mut Tの又貸しと言ってるのがどういうケースなのかはコードかないハッキリはわからないな

**デフォルトの名無しさん** · 2023/01/26(木) 17:21:49.46

implicitly reborrowedされるとhogeが&mut *hogeになるのか
勉強になった
ありがとう

**デフォルトの名無しさん** · 2023/01/26(木) 18:45:49.05

結局&mutを持っている間は専有しているから既存ルールに抵触することなく貸し出し自由自在という理解でいいのかな
&*でimmutableなreborrowも出来ちゃうもんね

**デフォルトの名無しさん** · 2023/01/26(木) 19:48:43.33

>>60
変数が値を所有しているんだよ
値がムーブされて一度無効化された変数にも新しい値を所有させられるよ
例えば、その9行目でxが3を所有していなかったとしても新しい値を入れられるよ
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=657d792c80f30e9430f0fbff11556fe6

**デフォルトの名無しさん** · 2023/01/26(木) 19:50:53.34

暗黙で参照が外されることがあるからわかりにくいんだろうな
最初から暗黙の参照外しがなければよかったと思うが
後方互換性を大事にするなら、もう改善は不可能だな

**デフォルトの名無しさん** · 2023/01/26(木) 20:31:02.62

>>53
だからバグじゃないよね？

**デフォルトの名無しさん** · 2023/01/26(木) 21:11:51.00

>>70
エラーを返すんだからpanicしないだろ

**デフォルトの名無しさん** · 2023/01/26(木) 21:14:28.71

>>68
そりゃmutならなw

**デフォルトの名無しさん** · 2023/01/26(木) 21:18:17.56

implicit reborrowはThe Bookには書かれないし直感的でもないから動きが理解しにくいというのはよく分かる

**デフォルトの名無しさん** · 2023/01/26(木) 21:50:47.31

>>70
例えばtwitterアプリを地下鉄とか通信できない状況で起動して panic で落ちる事を考えてみろ。そりゃバグだろ。

**デフォルトの名無しさん** · 2023/01/26(木) 22:06:21.53

Deref無しは流石にきついな
一気にRust書きたくなくなる気がする

**デフォルトの名無しさん** · 2023/01/26(木) 22:20:38.36

>>69
むしろderef含めたcoercionのおかげでRustは便利かつ読みやすいと思う
初心者の最初のうちだけは混乱するかもしれないけどそのデメリットを誤差にするほどの絶大なメリットがある

60 · 2023/01/27(金) 11:24:22.85

教えてくれてるのは本当にありがたいんですが、訳がわかんないぽ・・・・

**デフォルトの名無しさん** · 2023/01/27(金) 11:51:57.32

>>77
何がわからないのか書いて

60 · 2023/01/27(金) 13:58:30.55

マクロが展開するコードがあって、そこに&がついてるってことなんですか？

**デフォルトの名無しさん** · 2023/01/27(金) 14:00:09.55

せやで
Playgroundの左上のボタンでShow HIRするとマクロ展開等終わった後のコード出るから見てみ

**デフォルトの名無しさん** · 2023/01/27(金) 19:13:43.59

&はついてるけどあなたの疑問とは関係ないと思う

**デフォルトの名無しさん** · 2023/01/27(金) 21:29:03.39

>>74
例がtwitterアプリって...通信が出来ない状態でも何らかのオフライン操作が行えるアプリであればそうでしょうが
仕様上、エラーハンドリングを行わなければならないとされていないならバグではないでしょ....
むしろ大したログやコンソールでの情報も出さず、「エラー：通信ができましぇん」なんて返されるほうが迷惑だわ

**デフォルトの名無しさん** · 2023/01/27(金) 21:54:30.76

>>82
バグかどうかは仕様次第というのはそりゃそうなんだけど、それじゃ建設的な議論にならんでしょ。
俺はError返しといたほうが利用側がハンドリングする余地があっていいと思うね。

**はちみつ餃子** ◆8X2XSCHEME · 2023/01/28(土) 02:45:04.16

>>82
Rust の文化にあまり詳しいわけじゃないけど panic を呼び出すのって C/C++ で言うところの assert 的なもんでしょ。
普通に考えたら panic が呼ばれるのはモジュールの仕様に対して使い方が間違っているかリカバリ不可能な場合。
逆に言えば使い方が正しくてリカバリ可能な状況で panic になるべきではない。

モジュールの使い方が完璧に正しいプログラムを書いても panic が引き起こされてしまうなら panic の使い方のほうが間違ってる。
絶対に通信が確立する状況で使えという仕様を設定すりゃあ間違ってるのは使い方のほうではあるけどさー、
ネットワークでそれは不可能な前提じゃん？ありえない前提を元にするのは不毛だろ。

**デフォルトの名無しさん** · 2023/01/28(土) 07:46:19.92

>>82
> 仕様上、エラーハンドリングを行わなければならないとされていないならバグではないでしょ....
仕様バグ...

**デフォルトの名無しさん** · 2023/01/28(土) 09:58:07.00

ユーザーにとって不自然な動作をすれば開発者が仕様だと言い張ったところでそれはバグだよ

**デフォルトの名無しさん** · 2023/01/28(土) 10:54:36.16

エラーにも回復可能なエラーと不可能なエラーがあり、panicすると回復不可能な状態になるんだから、回復可能なエラーはpanicすべきじゃない。ましてや通常使用でしばしば発生する状態でpanicするのは言語道断だわな。

**デフォルトの名無しさん** · 2023/01/28(土) 10:57:15.78

assertというかexitやな。推奨はされん、普通はデバッグで面倒な時くらいじゃないか。

**デフォルトの名無しさん** · 2023/01/28(土) 11:52:23.17

>>86
MSの開発者を説得してくれ

**デフォルトの名無しさん** · 2023/01/28(土) 11:54:06.56

>>88
exitは正常終了でも呼ばれるからassertのほうが意味的には近いと思うぞ

**デフォルトの名無しさん** · 2023/01/28(土) 14:06:35.25

マルチスレッド界隈ではスレッドの一つや二つ終了しても
回復不可能と思ってないでしょ