Rust part29

**デフォルトの名無しさん** · 2025/05/03(土) 00:47:30.13

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

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

**デフォルトの名無しさん** · 2025/05/10(土) 18:06:29.45

我はガイジガガガイジ天地入れざる障害児

**デフォルトの名無しさん** · 2025/05/10(土) 18:11:29.44

不勉強で天地入れざると言う言葉を知らなかったが
明治とかの言葉なのかな？

学があるね

**デフォルトの名無しさん** · 2025/05/10(土) 18:22:28.75

>>352
ありがとう！
言葉を表面上の意味しか捉えられないガイジだけど、他人に迷惑かけるのは良くないよね…
スレ荒らしてすみませんでした…

**デフォルトの名無しさん** · 2025/05/10(土) 18:23:33.01

どうせ俺以外誰も見ていないから好きなだけ荒らせばいいと思うよ

**デフォルトの名無しさん** · 2025/05/10(土) 18:23:55.63

おちつきました。すみませんでした…

**デフォルトの名無しさん** · 2025/05/10(土) 18:29:52.94

>>352
抜刀隊の歌詞にあるから知ってた。
ミリタリー趣味の人ならまあまあ知ってるんじゃないかな。
私は音楽側の趣味で知ったんだけど。

**デフォルトの名無しさん** · 2025/05/10(土) 18:58:55.45

夏休みはまだ早いぞ

**デフォルトの名無しさん** · 2025/05/10(土) 19:15:47.47

業界には何らかの形でメンタルを病んでる人間が50万人以上いると思う

**デフォルトの名無しさん** · 2025/05/10(土) 19:53:17.55

このスレは特殊だから騙されないように

**デフォルトの名無しさん** · 2025/05/10(土) 20:19:31.95

自分は悪質でなければ荒らしを許容するスレにいた

そこでは荒らしとも楽しく話してそのうち荒らしが真面目なコテになったりしていた
みんなもうどこかに行ってしまったのが残念だけどそれも運命だなと

**デフォルトの名無しさん** · 2025/05/10(土) 20:45:49.44

病院行けよ
俺は今日行ったぞ

**デフォルトの名無しさん** · 2025/05/10(土) 21:12:29.85

unsafeなライブラリのラッパーでsafeに設計するのってどうやるの

**デフォルトの名無しさん** · 2025/05/10(土) 21:22:13.51

F-22 ada
F-35 C++

**デフォルトの名無しさん** · 2025/05/10(土) 21:48:52.45

>>362
結局のところ、外側から見て safe な振る舞いになるようにするというだけ。
場合によっては不可能なこともあるけど具体的な状況がわからないとなんとも言えない。

**デフォルトの名無しさん** · 2025/05/10(土) 21:52:02.98

>>362
未定義動作の可能性を排除するために必要な条件を全部チェックする
panicとデッドロックはOKらしい（停止すれば許される）

No matter what, Safe Rust can't cause Undefined Behavior.
https://doc.rust-lang.org/nomicon/safe-unsafe-meaning.html

**デフォルトの名無しさん** · 2025/05/10(土) 22:22:13.21

>>342
そういう低レベルな現場は無視してもいいんだよ
現在もJSのフレームワークは乱立しながら変化進化し続けているように多様性がある
今回の件と関係なくwasmを既に併用しているところも多いからその点もだいじょうぶ

**デフォルトの名無しさん** · 2025/05/10(土) 22:48:31.18

誰がその多様性とかについていくのか？
お前が低レベルな現場と呼ぶ環境だろう？

**デフォルトの名無しさん** · 2025/05/10(土) 23:29:16.41

フロントにRustを使ってる「高レベル」なプロダクトって何があるの？
バックエンドなら分かるけど
その基準なら世の中のビジネス的に成功してるサービスの殆どが低レベルでしょ

**デフォルトの名無しさん** · 2025/05/11(日) 00:02:17.99

>>364-365
関数の内側にunsafe書くだけ？
それだと見た目はsafeだけど内部はunsafeだから実質的にunsafeではないか？

**デフォルトの名無しさん** · 2025/05/11(日) 00:43:43.27

子供が使うバリアの高度版

**デフォルトの名無しさん** · 2025/05/11(日) 00:48:37.35

内部で使う関数がunsafeである理由を理解して未定義動作の可能性を排除できてないなら
外側の関数にもunsafeをつける約束

**デフォルトの名無しさん** · 2025/05/11(日) 00:49:47.08

unsafeは「危険」というよりも「コンパイラが安全性をチェックできない」ブロックだと思う
内部的に unsafe を使ってても、ラップした型や関数を外から使う分には安全とみなせるなら問題ない

理想的には
・内部的にunsafeを使っているけど、外から見れば安全 -> unsafe を外して良い
・内部的に unsafe を使っており、かつその関数は利用者が適切にコードを書かないと危険 -> その関数も unsafe とマークするべき

標準ライブラリやきちんとしたライブラリは基本的にこの法則に従ってる
問題はユーザーのコードで、書こうと思えば「問題はあるけど unsafe とマークされてない関数」は作れてしまう
そこは自己責任の問題

けど、セグフォみたいなバグが実際に起きた場合に、直接の原因となるコードは unsafe ブロックの中に絞れる (ことが多い) から、それでもかなりマシだと思う
C++だとコード全体が unsafe ブロックの中にあるようなものなので…

**デフォルトの名無しさん** · 2025/05/11(日) 00:50:52.82

>>365
Undefinedの有無もなにも標準化されてないからなぁ

**デフォルトの名無しさん** · 2025/05/11(日) 00:52:29.93

バリア！バリアしたから大丈夫！

**デフォルトの名無しさん** · 2025/05/11(日) 01:02:20.84

未完成らしいけど目安
https://doc.rust-lang.org/reference/behavior-considered-undefined.html

**デフォルトの名無しさん** · 2025/05/11(日) 01:18:27.03

unsafe ＝ Rustコンパイラが安全性を保証してくれない＝プログラマが自分の責任で安全性を保証しなければならない＝ C/C++と同じ状態

逆に言えば、safeつまりunsafeではない、とは、Rustコンパイラが安全性を保証できる状況にしないといけない
未定義動作がないことが根幹にある
だから未定義動作とは何か、どういう時に起きるのか、どうすれば無くせるのか、が最重要
それを完全に理解するまでは、関数内部でunsafeを使って外をsafeな関数、にする判断をしてはいけない

**デフォルトの名無しさん** · 2025/05/11(日) 01:20:41.47

unsafe functionは使いどころが微妙だね
unsafe指定の理由が不明だし基準も開発者次第でまちまち
C#みたいにunsafeにはコンテキストとしての役割しか持たせない方が一貫性がある
呼び出し元に注意させたいんならunsafe_hogeみたいなネーミングルールで十分だった

**デフォルトの名無しさん** · 2025/05/11(日) 01:31:46.55

バリアより感染症対策で流行ったゾーニングのイメージだな
感染リスクのあるunsafeゾーンと安全なsafeゾーンがあって
unsafeからsafeに持ち込むときは消毒（検査）が必須みたいな感じ

運用が雑になって事故るのも同じ

**デフォルトの名無しさん** · 2025/05/11(日) 01:36:40.21

>>376
> それを完全に理解するまでは、関数内部でunsafeを使って外をsafeな関数、にする判断をしてはいけない
それをやると、一つの関数を unsafe にした時点でそれが呼び出し元に波及して、プログラム全体に unsafe が広がらない？
深刻なバグがコード内のどこで起こってるかを特定したい場面だと、 unsafeは本当に unsafe な操作をしてる箇所に限定されてた方が探しやすいと思う

**デフォルトの名無しさん** · 2025/05/11(日) 01:47:17.60

>>377
呼び出し元に注意を持たせるものではない
unsafeブロック(関数)内はRustコンパイラが安全性を保証しない
それ以外の部分はRustコンパイラが安全性を保証してくれる
C/C++はプログラム全体がunsafeブロック内にある状況と同じと説明できる

>>379
そうだよ
理解するまではunsafeを使ったらunsafeな関数しか作れない
safeな関数にしてよいかどうかの判断が一番大事なところ
勝手に判断してsafeにしたらプログラム全体に問題が波及しかねない
まずは理解してからunsafeに手を出しましょうということ

**デフォルトの名無しさん** · 2025/05/11(日) 02:07:37.23

「unsafe利用箇所をunsafeブロックで囲えば終わり」は、よくある勘違い
まず一次的には「それを含む関数もunsafe fnにしなければならない」が正解
その上で「内部でunsafeを使ったことで生じる問題が、その関数単独でまたはモジュール全体で閉じ込めることができているかを判断できてから、ようやくunsafe fnをfnにできる」が正解

**デフォルトの名無しさん** · 2025/05/11(日) 06:19:57.03

unsafeな理由をブロック外部で処理すりゃsafeに出来るじゃん
たとえばなraw pointer参照が危険だとして渡す前にスタックまたはヒープ内の正しいアドレスであることを確認して引数を渡すとかの、外部でのチェック(unsafeに至る条件の排除)すれば無毒化できるわけで

そんなんC言語だって変わらんやん。Cで汎用的な関数書いたらほぼほぼポインターだらけになるし、ポインターのチェックせずに使うなんてことは危険すぎてありえんのと一緒やん

C言語にrustコンパイラーのunsafeの枠組みだけ組み込んでsafeじゃなきゃエラーにしますにしたら、コードの5割ぐらいはunsafeになってそうやけどな。標準ライブラリーからしていくらでも危険なアクセスできるし

**デフォルトの名無しさん** · 2025/05/11(日) 07:03:44.41

>>382
Rustでプログラミングしたことない人には理解できないのは仕方ないが的外れ
そのCで手動でチェックをして使うようなことは
Rustではunsafeを使わずとも普通に書くことができて自動的にチェックしてくれて安全かつ楽

むしろRustでunsafeを使う頻出パターンの一つは真逆
その自動チェックを無くすためにunsafeが使われる
例えばあるアルゴリズムで既に自動チェックされて既に安全なものがアルゴリズムの都合で二重に自動チェックされてしまいコンパイルでの最適化でも消えないとする
その2回目の自動チェックを無くすためにunsafeを使う
もしそのアルゴリズムが1つの関数で完了するならばその関数外に影響はないため
関数内部でunsafeを使っていても関数自体は外向けにsafeにすることができる
そのアルゴリズムで2回目の自動チェック省略が常に正しく安全なことはプログラマが安全性を保証することになる
これがunsafeを用いて極限まで速くしつつ安全な関数を生み出すRustの典型的なパターン

**デフォルトの名無しさん** · 2025/05/11(日) 08:49:42.45

https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html
これが全て
unsafe function に関しては、長文複おじが主張するほどunsafeを含む関数に対して積極的に指定すべきものではなく、
むしろ極力safeとしてラップすることを推奨するトーンで書かれているように感じる
「unsafe functionは呼び出し元に注意させるためのマーク」という解釈は適切であり、常識的に考えて中でunsafe使ってようと呼び方によって未定義動作が生じるような関数はそもそも作るべきではない

**デフォルトの名無しさん** · 2025/05/11(日) 09:06:54.66

unsafe指定の理由が不明って斬新な視点だと思うけどね
他の言語でunsafe使ってるから意味は理解出来る

**デフォルトの名無しさん** · 2025/05/11(日) 09:11:42.89

>>384
逆だぞ
未定義動作が発生しうるパーツがunsafe関数
そのパーツを上手く使ったり組み合わせたりして未定義動作を発生させなくしたものがsafe関数

**デフォルトの名無しさん** · 2025/05/11(日) 09:15:33.06

変わった人が集まって3行で済んでいた話を広げていく

**デフォルトの名無しさん** · 2025/05/11(日) 10:06:07.52

>>368
無いから自演してまでしてRustを盛り上げようしてる

**デフォルトの名無しさん** · 2025/05/11(日) 10:11:53.93

ここスレが立って1週間で300レスかよ
さすが究極のプログラミング言語だけあるな
関心持つ人多すぎ

**デフォルトの名無しさん** · 2025/05/11(日) 11:15:42.58

>>369
その理屈だとRustで描かれたコードはすべてunsafeだ

**デフォルトの名無しさん** · 2025/05/11(日) 11:22:17.69

>>389
何なんだよこの気持ち悪い複オジのレスはw

**デフォルトの名無しさん** · 2025/05/11(日) 11:30:45.60

>>383
borrow mut な部分を unsafe {} で囲むとコンパイル通せるんだっけ？

**デフォルトの名無しさん** · 2025/05/11(日) 11:38:18.14

>>392
unsafeであろうとRustの参照ルールは変わらない
ナマポ受給は可能

**デフォルトの名無しさん** · 2025/05/11(日) 11:38:36.95

unsafeで囲むとその中で危険な必殺技が使える
強力だけどその間はリミッター解除され保護されていない状況にも近い諸刃の剣
それを呼び出す部位もunsafe扱いしたらmainまでunsafeになり危険極まりないｗ

**デフォルトの名無しさん** · 2025/05/11(日) 11:48:02.09

やってることはC言語でコメントにunsafeって書くのと変わらねえじゃん

**デフォルトの名無しさん** · 2025/05/11(日) 11:53:03.94

違いが判らないなら理解力が不足しているだろう
unsafeだと通常は許されないことが可能になる

**デフォルトの名無しさん** · 2025/05/11(日) 12:00:44.68

>>395
全く異なる
Rustではunsafe部分のみ人間が安全性を保証する義務がある
それ以外はRustの言語仕様により自動的に安全性が保証される
一般プログラマはunsafeを使う必要がない

**デフォルトの名無しさん** · 2025/05/11(日) 12:19:58.74

>>396
俺が言ってる意味がわからない方が理解力が不足してるかもよｗ

**デフォルトの名無しさん** · 2025/05/11(日) 12:37:43.07

>>398
unsafeじゃない部分を無視してそれを言うのは意味がないこと
typescriptで書かれたコードがjsに変換されてそれに型が残っていないと言うのと似たような主張

**デフォルトの名無しさん** · 2025/05/11(日) 12:41:23.78

他の言語でもunsafe以外では保護されている部分もunsafeで制約が解除されている

**デフォルトの名無しさん** · 2025/05/11(日) 13:01:06.68

>>369
unsafeな関数には関数を呼び出す側が守るべきsafetyルールがそれぞれ定義されている
ラッパー関数がそのルールを関数内のみで不変的に守ることが保証できるのならsafe
できないなら上位で保証してもらう必要があるからunsafe

いずれにしてもunsafe関数を呼び出す側が守るべきsafetyルールは
アプリケーションのどこかの段階ではすべて守られることを保証しないといけない

**デフォルトの名無しさん** · 2025/05/11(日) 13:53:51.61

>>396
その理屈だと二重の borrow mut も unsafe{} で許可してもらえるととってもありがたいんだが

**デフォルトの名無しさん** · 2025/05/11(日) 14:09:26.63

>>402
unsafeの使用は安全性を守るためだけに使われるのだ
安全を脅かすためにunsafeを用いてはならないのだ

**デフォルトの名無しさん** · 2025/05/11(日) 14:48:00.02

>>396
unsafeブロック内でも外でもRustのルールは基本的に同じ
何でも出来るようになるわけではない

unsafeブロック内でのみ出来ること
・unsafeな関数やメソッドの呼び出し
・unsafeなトレイトの実装
・生ポインタの逆参照
・共有体フィールドの読み取り
・可変静的変数の読み書き
このたった5つのみが許可される

**デフォルトの名無しさん** · 2025/05/11(日) 16:26:32.64

文意を取れない病気なのだろうか？

**デフォルトの名無しさん** · 2025/05/11(日) 17:38:39.22

まあ病気だろうね

**デルフォトの名無し** · 2025/05/11(日) 20:01:04.55

unsafeってそんなに不味いんですね...

**デフォルトの名無しさん** · 2025/05/11(日) 20:20:01.31

特殊な環境を抜きにすると普通の開発でunsafeが使われることはほとんどない
むしろコンセンサス無くunsafeを使う人がいたら問題児認定されても仕方ない
ボトルネックがあってunsafeを使うことで安全かつ劇的に改善されるなどの共通認識が出来たら注意深くみんなの監視の下で使われる

**デルフォトの名無し** · 2025/05/11(日) 20:23:01.43

特殊な環境って...具体的にどういうのがあるんですかね...

**デフォルトの名無しさん** · 2025/05/11(日) 21:10:41.96

安全に使うための条件が分からないunsafeは不味い
標準ライブラリのunsafe関数は大体Safetyで明示してる

**デフォルトの名無しさん** · 2025/05/11(日) 23:58:19.36

>>378
メモリに対するバリアはunsafeを必要とせずにsafe Rustで使える
モデルはC++と同じでstd::sync::atomic::AcquireとReleaseでバリアを構成する

**デフォルトの名無しさん** · 2025/05/12(月) 11:03:30.61

OS提供のヘッダーファイルと連携しないといけないからね
rustだってOSのAPIとして使われるようになったら今の形のままでは済まされないはず

**デフォルトの名無しさん** · 2025/05/12(月) 11:09:27.48

その頃にはもう人間がAPIを管理することはないだろうから我々が気にする必要はない

**デフォルトの名無しさん** · 2025/05/12(月) 11:22:05.12

atomicを使える局面なら最速を狙えるが
素人は無難にMutexにしとけ

**デフォルトの名無しさん** · 2025/05/12(月) 11:51:31.03

処理が性能上クリティカルじゃないことが分かってる上で手を抜くのはいいけど、必要に応じてロックフリーを実装できないレベルならさすがに言語の選択から考え直すべき
場合によっちゃゲロ遅スクリプト言語でロックフリーに書かれたコードより遅くなるぞ

**デフォルトの名無しさん** · 2025/05/12(月) 11:55:41.87

誰もメモリバリアの話なんかしてないだろストローオジ

**デフォルトの名無しさん** · 2025/05/12(月) 11:57:36.67

>>415
その通り

**デフォルトの名無しさん** · 2025/05/12(月) 12:21:58.09

>>415
ロックフリーにできるならatomicを使う方が当然よい
しかし素人がABA問題からRISCのアクセス順序崩壊まで様々な問題を理解しつつ
compare_exchange系などを正しく使いながら各々のRelaxed/Release/Acquired/SeqCstを最善に選べると思えない
複数のatomicが複雑に絡むとロックフリーはプロでも間違える歴史を繰り返してきた分野だ
さらに言えばatomicよりMutexが有利になるケースの存在も理解して適切に選ぶ必要がある
プロでも単純明快な状況でない場合はまずMutexで実装して後から見極めた上でatomicにするかどうか決める
これらの知識を身に付けるまで素人は無難にMutexにしとけ

**デフォルトの名無しさん** · 2025/05/12(月) 15:44:13.42

unsafeについて
https://www.youtube.com/watch?v=lx86iUb2xiI

**デフォルトの名無しさん** · 2025/05/12(月) 22:25:38.81

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=18df19416bd6d705356724788636ab13
これをResultのmapとかand_thenとかを使ってスッキリ書く方法ってないでしょうか？

**デフォルトの名無しさん** · 2025/05/13(火) 00:03:38.80

>>420
let z = x.or(y).or(Err("ko"));

？

**デフォルトの名無しさん** · 2025/05/13(火) 00:12:19.92

>>421
x=Some(false), y=Some(true)のときz=Some(false)になるからダメじゃね？

**デフォルトの名無しさん** · 2025/05/13(火) 00:18:54.30

すまんOptionとResult勘違いしてた

**デフォルトの名無しさん** · 2025/05/13(火) 00:29:45.70

>>422
たし🦀

let z = x.and_then(|b1| y.map(|b2| b1 || b2).or(Ok(b1))).or_else(|_| y.or(Err("ko")));

直したらこんなんなったんだが
matchが一番わかりやすい気がする

**デフォルトの名無しさん** · 2025/05/13(火) 00:30:51.37

x.map(|x| y.map_or(x, |y| x || y)).or(y).or(Err("ko"))とかになるからmatch以上にスッキリ書く方法はないんじゃないかな

**デフォルトの名無しさん** · 2025/05/13(火) 00:46:34.37

一応x,yが増えた時のためにイテレータ使うパターン
let z = [x, y].into_iter().filter_map(Result::ok).reduce(|b1, b2| b1 || b2).ok_or("ko");

２つならmatchでいい気がする

**デフォルトの名無しさん** · 2025/05/13(火) 07:26:56.06

たくさんある時はOk(true)でショートカットしたいケースが多そう
例えば素直に

let mut is_ok = false;
while let Some(x) = iter.next() {
　match x {
　　Ok(true) => return x,
　　Ok(_) => is_ok = true,
　　_ => (),
　}
}
is_ok.then_some(false).ok_or("ko")

**デフォルトの名無しさん** · 2025/05/13(火) 07:31:54.57

幻聴で半分人間半分AIと話していたので
1 私に成りすまして話しているようにいさせている
2 成りすましの声でも身体攻撃の部分は私本人も同じ状態に陥っている
3 犯人が使用していたとしても清廉潔白の人物のように見せれる

【2025年最新】自然な声の音声読み上げソフト5選！AI技術で ...
https://ondoku3.com/ja/post/natural-voice-software/
※インストール不要で無料で５０００文字まで複数声質の音声合成エンジンで読み上げ可能

ローカルで各種AIモデルを実行できる無料ソフト「llama.cpp」がマルチモーダル入力をサポートし画像の説明などが可能に
2025年05月12日 20時00分
https://gigazine.net/news/20250512-llama-cpp--multimodal-vision-support/
>>llama.cppの詳細情報は以下のリンク先で公開されており、ソースコードやインストール手順などを確認できます。
※画像を認識させてテキスト入力が可能

ローカルでAIを動かして「コード生成」「ウェブ上の情報収集」「ファイル検索」などの操作を実行できるAIエージェント「AgenticSeek」、無料で使えてプライバシーも守れるのが強み
2025年05月05日 16時02分
https://gigazine.net/news/20250505-agenticseek-local-ai-agent
>>AgenticSeekのインストール手順は以下のページにまとまっています。
※複数サイトからレポート作成可能

**デフォルトの名無しさん** · 2025/05/13(火) 10:17:11.92

>>422-423
このようにRustは面倒

**デフォルトの名無しさん** · 2025/05/13(火) 10:29:55.43

>>429
その点ではRustが最も優れています

**デフォルトの名無しさん** · 2025/05/13(火) 11:06:20.16

優れてるなら間違わないように設計汁

**デフォルトの名無しさん** · 2025/05/13(火) 11:13:08.18

>>431
Rustは強い静的型付け言語なので間違えることはありません

**デフォルトの名無しさん** · 2025/05/13(火) 12:48:35.47

>>429
わかるわ
ResultやOptionはわりと継ぎはぎだらけでasyncでの使い勝手もあってコアな開発者でもコンビネータよりもmatch推奨する人が増えてる

**デフォルトの名無しさん** · 2025/05/13(火) 14:00:36.56

>>433
継ぎはぎはない
根本の理解を間違えているからそんな変な発想になる

基本はmatchで書くのが当然
例えば
match foo {
　Some(x) => Some(f(x)),
　None => None,
}
こう書いた時に意味するところはSome時にfによる写像
だからこれをfoo.map(f)と略記できるというのが根本
短く記述でき可読性も上がる

asyncでの使い勝手というのも同様
このfの形とクロージャでのキャプチャなどの制限を満たせば使えて満たさなければ使えないだけの話
matchを推奨しているのではなくmatchが基本
そのうえで可読性がよくなるメソッドが適用できるならそれを使う
メソッドチェーンもそれで短く可読性が上がるなら使う
>>420はmatchのままが可読性がいい
それだけの話

**デフォルトの名無しさん** · 2025/05/13(火) 14:18:16.15

だからRustは清書用(キリっ)って言われるんだろうね

**デフォルトの名無しさん** · 2025/05/13(火) 14:28:55.14

>>435
そんな話は聞いたことない
今回の話との関連すら不明

**デフォルトの名無しさん** · 2025/05/13(火) 16:46:51.79

>>434
またバカおじの意味のない長文
アンチRust活動は他所でやれ

**デフォルトの名無しさん** · 2025/05/13(火) 18:59:19.16

>>433
確かに最初の頃に比べると
イテレーター&コンビネーターの使用頻度がやや下がって
代わりにループ&マッチの使用頻度が上がったな

冗長でダサく感じるけど汎用性が高まる場合が多い

**デフォルトの名無しさん** · 2025/05/13(火) 19:20:56.54

早期脱出はループで書くほうがわかりやすいものやループでしか実現できないことも多い
特にラベル指定など

**デフォルトの名無しさん** · 2025/05/13(火) 19:50:54.91

実際どうなるかなんてその時次第だから

今回は結果をまとめて出してるんだろうけど
それぞれの実行結果で制御が加われば別に結果をまとめる必要はない場合もでて来るので綺麗に書ける必要はゼロ

**デフォルトの名無しさん** · 2025/05/13(火) 19:51:24.47

>>420
ちょっと主旨から外れるけど、matchは
match (x, y) {
(Ok(b1), Ok(b2)) => Ok(b1 || b2),
(Ok(_), _ ) => x,
_ => y,
};
まで整理できますね。
2回評価するのが嫌なら二段matchがいいかと。

**デフォルトの名無しさん** · 2025/05/13(火) 19:57:18.96

綺麗だねｗ

**デフォルトの名無しさん** · 2025/05/13(火) 20:06:13.63

実際にはOk/Err得られた時点で既に実行済みだからその後の工夫は効果薄くて
>>427のような早期脱出になるかな
next()呼び出しで実行されるとして

**デフォルトの名無しさん** · 2025/05/13(火) 20:08:00.80

関数の実行結果x,yがあります
それぞれのx,yが成功していればそれを出力してください
ただしｘ,y共に成功であれば結果を論理和して出力してください
x,y共にエラーである場合はエラーを出力してください

**デフォルトの名無しさん** · 2025/05/13(火) 20:15:06.96

結果が揃っていたら悩むところないよな
現実には結果が一部しか出ていない段階で欲しい結果が得られたから以降は打ち切り、または、エラーが出たから打ち切り

**デフォルトの名無しさん** · 2025/05/13(火) 20:46:34.57

二段matchも書いてみた。
let z = match x {
Err(_) => y,
Ok(false) => match y {
Err(_) => x,
_=>y,
},
_ => x,
};
普通はこんな書き方しないだろうけど。

**デフォルトの名無しさん** · 2025/05/13(火) 21:23:14.88

まあしかし
元の

let z = match (x, y) {
(Ok(b1), Ok(b2)) => Ok(b1 || b2),
(Ok(b1), Err(_)) => Ok(b1),
(Err(_), Ok(b2)) => Ok(b2),
(Err(_), Err(_)) => Err("ko"),
};

これが一番可読性高くて網羅性も一目でわかっていいと思うわ

**デフォルトの名無しさん** · 2025/05/13(火) 21:30:58.39

結局のところは意図が表れていて読み取りやすいことが重要で、スマートに書けてても見た他人がなんのこっちゃとなるようではあかんからな。

**デフォルトの名無しさん** · 2025/05/13(火) 22:06:17.20

>>446
蛇足だけど、こっちの方がいいか。
let z = match x {
Err(_) => y,
Ok(true) => x,
_ => match y {
Err(_) => x,
_=>y,
},

};

**デフォルトの名無しさん** · 2025/05/13(火) 22:11:12.56

他の言語でもあるんだけど元々シンプルに書けていたものを
その言語特有の機能で書き換えたい勢がいる

パズルとしては別に構わないけどそれでどれだけ時間を費やすのか考えてなさそう