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/05(日) 21:31:31.79

多数の下部ライブラリから色んなエラーが上がってくるreqwestはそれらをdyn std::error::Errorへ入れているね
そしてdowncast_refで必要な分岐をして処理しているね
エラー処理はこれで十分でしょ
網羅しなくても残りは最終的にちゃんとエラー表示されるのだから

**デフォルトの名無しさん** · 2023/02/05(日) 22:59:47.83

エラー処理で必須な網羅性とはenumの網羅性とは異なる
いつどこでどんなエラーが発生しても必ず処理されることがエラー処理の網羅性
つまりエラー処理されないまま通常処理に進まないことでありRustではResultの利用によりそれが保証されている
したがってdyn Errorを使って一部をダウンキャストによりエラー処理し残りをエラー表示処理でも網羅性を満たしている

**デフォルトの名無しさん** · 2023/02/05(日) 23:51:35.27

opaqueなerror typeを使うメリットは何なのか？デメリットは何なのか？
少なくともreqwestの開発者はそのトレードオフを検討した上で判断を下している

メリットもデメリットも理解できてないやつが珍説唱えても虚しいだけだぞ

**デフォルトの名無しさん** · 2023/02/05(日) 23:54:47.07

>>390
おまえはエクストリームな言い訳並べ立てる前にnon_exhaustiveの意味から調べろな

**デフォルトの名無しさん** · 2023/02/05(日) 23:58:58.86

>>390
やっぱりそれでいいのか
Rustの標準IOライブラリはenumを使っているけどnon_exhaustive指定がしてありenumの網羅性チェックをむしろ使えないようにしてる

**デフォルトの名無しさん** · 2023/02/06(月) 00:09:01.18

>>390
一般的なエラー処理の網羅性はその解釈だな
Rustでは型システムと返り型Result及びResult放置をコンパイラが警告してくれるため必ず網羅される仕組み

**デフォルトの名無しさん** · 2023/02/06(月) 01:23:09.90

>>393
non_exhaustive指定があると
なぜenumの網羅性チェックが使えないの？

**デフォルトの名無しさん** · 2023/02/06(月) 06:52:59.94

逆だよ
網羅性の扱いを禁止するために意図的にnon_exhaustive指定されている
そのようなエラーの種類には網羅性は必要がないだけでなく
今後もしエラーの種類が増えた場合に全網羅列挙して使用している既存のコードがエラーとなってしまう
そのためこういう時は不要である網羅性の扱いを禁止して全列挙コードを書かせないことで
今後エラーの種類が増えても既存の利用コードに影響を与えずに済む仕組み

**デフォルトの名無しさん** · 2023/02/06(月) 12:30:43.08

>>396
自信満々に間違った情報を中身のない文章で膨らませてもっともらしく見せようとするところがChatGPTそっくりww

**デフォルトの名無しさん** · 2023/02/06(月) 12:48:04.84

昔ながらの例外論争見てるみたいだ
全部取ればいいいや個別だ

**デフォルトの名無しさん** · 2023/02/06(月) 14:14:21.50

>>396で合っているけど補足すれば
全網羅列挙コードを書いてもコンパイラがそれを許さずエラーとなる
全網羅列挙しなくていいから必ず全マッチの　_ =>　アームをコンパイラが要求してくる
つまりコンパイラによるエラーの網羅性チェックは不可能

**デフォルトの名無しさん** · 2023/02/06(月) 21:51:09.46

そもそもRust以前に他のプログラミング言語でもそのようなエラーの種類の網羅が行なわれたことはない
IOエラーだけでも何十種類もあり列挙するだけでも大変で意味のない作業
エラー処理で必要とされる網羅性とはエラーの種類を全て列挙することではなく
>>390の説明が正しい
RustでResultを使えば保証される

**デフォルトの名無しさん** · 2023/02/06(月) 21:59:33.19

自分の書いたレスを正しい正しいと
一人で連呼してて虚しくならないのかな

**デフォルトの名無しさん** · 2023/02/06(月) 22:26:04.02

エラー処理の網羅性という話は元々
関数からエラー値が返って来る可能性があるのに見落として処理せずに続行しちゃったり
あるいは例外が返って来る可能性があるのに見落として処理しないままでいたり
そういう見落としがよく起きていたから
いつどこでどんなエラー(or例外)が起きても処理漏れがないようにプログラミングしましょうという話

もちろんRustではResultで返せばコンパイル時点でエラーや警告が出るためエラー処理の網羅性は満たされます
Resultを返していればdyn Errorやanyhowを使っていてももちろん大丈夫
そしてエラー処理の分岐にそれらのダウンキャストを使うのも何ら問題なし

**デフォルトの名無しさん** · 2023/02/07(火) 02:02:21.05

anyhow使ってて困ったことないので、これからもanyhow使いますね

**デフォルトの名無しさん** · 2023/02/07(火) 02:09:15.61

enumで網羅派の完全敗北だな
anyhowやdyn Errorでdowncast_ref分岐して何ら困らない

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

anyhowは邪道だろ

**デフォルトの名無しさん** · 2023/02/07(火) 10:30:33.69

下手に分かったふりせず疑問をぶつけるパニック君のようなレスはスレにとっては有益
逆に知ったかぶりして嘘を撒き散らす某オジのレスは害しかない

一緒に仕事してても伸びるのは断然前者のタイプ
後者は多少知識があってもチームの足を引っ張る老害タイプ

**デフォルトの名無しさん** · 2023/02/07(火) 11:56:13.05

>>406
知ったかぶりもだけど
ご飯論法的に毎回論点を捻じ曲げてくるのが悪質
スルー推奨

**デフォルトの名無しさん** · 2023/02/07(火) 12:39:13.84

どの言語を使っていようがテスト設計とエラー処理設計は初心者と脱初心者を見分けるリトマス試験紙
チュートリアルやリファレンス読むだけでは身につかない

**デフォルトの名無しさん** · 2023/02/07(火) 13:41:38.43

そう、IT土方必修

**デフォルトの名無しさん** · 2023/02/07(火) 20:09:18.77

>>409
こういうバカが一人でも入ってくると現場は苦労するわな

**デフォルトの名無しさん** · 2023/02/07(火) 22:03:06.31

今回のケースはRustのエラー処理を他の言語（C#あたり）の例外処理に寄せようとしてる感じ
「特定の例外クラスをcatchしたい」→「dyn Errorで投げてダウンキャストで分岐すればいい」みたいな
anyhowはそういう人のためにあるのかもしれない

オブジェクト指向言語専攻の人はRustのtraitを基底クラスの代わりに使いがちだよね
is-a継承はRustだとenumで表現できる場合が多いんだけど切り替えが難しいのかも

**デフォルトの名無しさん** · 2023/02/07(火) 22:27:27.04

単純にエラーの種類を列挙する意味がないときに使うだけやで

**デフォルトの名無しさん** · 2023/02/07(火) 23:09:28.73

それならいいんだけど型キャストしてまで分岐するとか言ってる人がいたから
自分で分岐する範囲くらいは自分で列挙しとけって話

**デフォルトの名無しさん** · 2023/02/07(火) 23:53:31.04

下層から上がってくる99種類のエラーはログ吐かせるだけで、特別な処理したいエラーはひとつしかないのにいちいちenumに詰め直したりせんわな

**デフォルトの名無しさん** · 2023/02/08(水) 00:04:28.76

逆
自分で分岐してエラー処理すんなら区別すべきエラーを決めるのは自分なのでanyhowやdyn Errorでダウンキャストしても問題ない

外から呼び出されるコードなら区別して処理するエラーを決めるのは呼び出し側なので区別できるようにenumで書く

**デフォルトの名無しさん** · 2023/02/08(水) 00:35:28.79

すまんが、これってなんでダメなの？
ブロックの最後に式を書いてるのに、なんでreturnって書かないとリターンしないの？？？
そもそもエラーの内容に書いてあるmismatched typesって、一体何と何のタイプがミスマッチなんなんだ・・・・
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=d1833710038ed821593015e5382de11f
エロい人教えて！！！

**デフォルトの名無しさん** · 2023/02/08(水) 01:51:02.48

>>416
else句が無いのでifの条件式がfalseの場合はif-expressionは()になるけど
ifの条件式がtrueの場合はif-expressionがi32になるのでミスマッチ

**デフォルトの名無しさん** · 2023/02/08(水) 01:59:22.59

>>414
ログを吐かせるだけでもエラーによってログの吐き方を変えたいこともよくある話なのでケースバイケース
99種類を2種類に詰め直して片方をerased typeにしたりする

**デフォルトの名無しさん** · 2023/02/08(水) 07:28:48.49

上位の関数でもかなり多数のケースに分けてエラー処理する必要な場合だと
個別にenumにエラー型を収容する方が有利なケースもある
もちろんその場合でもanyhowやdyn Errorに収容してダウンキャストしてもよい
enum matchとダウンキャストの実行時コストはほぼ同じで優劣はなく視認性も変わらない
enumを使うとコードが増える問題はあるがあとは好みの問題

**デフォルトの名無しさん** · 2023/02/08(水) 10:45:01.05

ダウンキャストは下位モジュールに不必要に依存することになるので選択の余地があるなら基本的には使うべきではない

自crateで定義したエラー型にダウンキャストするくらいならエラーを定義するついでにenum書いとけばいいだけ
他crateで定義したエラー型にダウンキャストしてるとバージョンアップ時にサイレントにキャストが失敗して動作が変わる

あくまで非常口であって使わざるをえないときはマイナス面を理解した上で注意深く使うもの

**デフォルトの名無しさん** · 2023/02/08(水) 10:52:13.58

UnknownErrorにわざわざ詰め直したログ吐くしかできない99種類あったエラーと1種類の自クレートのMyErrorをenumで2つ列挙して分岐するのと
MyErrorも含めて100種全部dynで上げてMyErrorだけダウンキャストすることの間に大した違いはない

**デフォルトの名無しさん** · 2023/02/08(水) 12:29:34.73

アプリケーション開発とライブラリ開発の2つの視点があって、それぞれで戦略が違うというのが大元にあるからそこは理解してもらわないとね。

**デフォルトの名無しさん** · 2023/02/08(水) 12:40:19.14

ライブラリでdyn Error使うと本体の型がpubじゃないときにめんどくさそう

**デフォルトの名無しさん** · 2023/02/08(水) 12:45:18.46

両者で大きく異なるよね
ただし既出のcargoやreqwestなど違いに関わらずダウンキャストを使っているコードも多いから
どっちだと良くてどっちだとダメというものでもない気がする

**デフォルトの名無しさん** · 2023/02/08(水) 12:48:39.58

424は422へのレスね

>>423
そこはenum作って収容しようがdyn Errorに収容しようが関係なくpubじゃない型はどうにもならないような

**デフォルトの名無しさん** · 2023/02/08(水) 13:05:56.18

>>421
どういう種類の変更に対してコードのどの部分に手を入れる必要が出てくるのかを考えてみるといいよ

**デフォルトの名無しさん** · 2023/02/08(水) 13:15:25.12

求められてもない具体性のない中身のない全く役に立たないアドバイスは有害でしかない

**デフォルトの名無しさん** · 2023/02/08(水) 13:35:42.99

現実にdowncast_ref()が使われているアプリやライブラリが多数あり
それらが問題になったことはないのだから
downcast_ref()を嫌っている人は思い込みで好き嫌いに過ぎないことを理解しようぜ
enumを作っても下位のエラー型を突っ込むだけでは何も変わらない

**デフォルトの名無しさん** · 2023/02/08(水) 14:12:14.99

ここまで具体的なコード例なし

**デフォルトの名無しさん** · 2023/02/08(水) 14:40:13.85

前提条件付けて場合分けして考えろ
てかこんなことでスレの半分近くも消費すんな

**デフォルトの名無しさん** · 2023/02/08(水) 16:15:41.93

>>417
そうだったのか！returnを書いたら通るのも、そうするとどちらも戻り値が()同士で統一されるってことか！
ありがとう！全然わかんなかったぜ！

**デフォルトの名無しさん** · 2023/02/08(水) 16:16:54.39

>>417
>>416では無いが、そういう意味だったのか
単に厳し目にチェックしているからだと思っていた

**デフォルトの名無しさん** · 2023/02/08(水) 17:13:58.11

たぶんだけど「Rustでは値を返すのにreturnを省略できる」と誤解してるんじゃないかな
その誤解のためreturn bのreturnを省略してしまったと思われる

正しくは「Rustでは最後の値が返り値となる(のでreturnが不要)(だが使ってもよい)」
と「途中で返したい時はreturnを使う」

だから今回の例だと
if文の中では『途中だから』return bとbにreturnが必須
あるいは関数の最後をif-else式にしてしまえば『最後となるから』bにreturnは不要

**デフォルトの名無しさん** · 2023/02/08(水) 17:28:24.72

ちょっと誤解があるから追加
最後をif-else式にすれば全体に式returnのreturnが不要になる
そしてif-else式の中はreturnは不要というか付けない
そこにreturnを付けるとif-else式ではなぬif-else文になる

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

文章を難読化しすぎやろw

**デフォルトの名無しさん** · 2023/02/08(水) 18:22:49.80

面倒だから戻るところはすべてreturn書いてる

**デフォルトの名無しさん** · 2023/02/08(水) 20:39:29.96

return式の型は厳密には!なんだけど……
まあ後で知ればいいか

**デフォルトの名無しさん** · 2023/02/08(水) 20:50:18.79

そのおかげでif式でreturnしつつelseで値を与えたりできるね

**デフォルトの名無しさん** · 2023/02/09(木) 11:57:24.62

早期returnはバグにつながるから禁止が常識

**デフォルトの名無しさん** · 2023/02/09(木) 12:14:59.38

>>439
昔はそう言われたけど今はそんなカス風習廃れたしRustに持ち込まないでほしい。

**デフォルトの名無しさん** · 2023/02/09(木) 12:15:50.03

早期returnは（>>439みたいなアホが使うと）バグにつながるから禁止が常識

**デフォルトの名無しさん** · 2023/02/09(木) 12:41:16.10

わざわざ早期リターンのために?演算子なんて用意してるRustで早期リターン禁止とな？！

**デフォルトの名無しさん** · 2023/02/09(木) 12:43:02.37

スルースキル皆無か

**デフォルトの名無しさん** · 2023/02/09(木) 13:10:12.86

なんで昔は早期returnがバグにつながると考えられてたの？
どう考えても早期returnしない方がバグにつながりやすいと思うんだが

**デフォルトの名無しさん** · 2023/02/09(木) 14:20:08.85

もっと昔にgotoの使いすぎで制御構造がぐちゃぐちゃになったことへの反動で
複雑な制御構造は使わないようにしよう、という流れだったかと

**デフォルトの名無しさん** · 2023/02/09(木) 14:55:47.47

>>444
C言語時代の話な
例えばこういうパターンでメモリーリークしたりするバグがたくさんあった

f(...){
p = malloc(...);
...
if(...) return;
...
free(p);
}

**デフォルトの名無しさん** · 2023/02/09(木) 15:21:57.59

そのあたりも自動メモリ開放のRustなら大丈夫だね
if文で早期return/continue/breakしないと、どんどんifネストが深くなっていくのでそれを避けたい

**デフォルトの名無しさん** · 2023/02/09(木) 15:37:28.09

>>446
リソース確保・解放するレイヤーとそれを使って処理を行うレイヤーを分ければよくない？

f(...){
p = malloc(...);
g(p, …);
free(p);
}

g(…) {
...
if(...) return;
...
}

ifのネストが浅くなっても逆に関数のネストが深くなりすぎて読みにくくなる側面があるということなのかな？

**デフォルトの名無しさん** · 2023/02/09(木) 15:51:48.67

>>448
分けましょうってルール化したくらいで完璧に守られるなら誰も苦労しないんだよな…
そのうち処理レイヤー側でmallocするやつが出てくるやつ

**デフォルトの名無しさん** · 2023/02/09(木) 15:59:20.91

RAII無しでの話なんかRustに関係無いだろ。

**デフォルトの名無しさん** · 2023/02/09(木) 16:04:18.76

ifがネスとしていたりした場合に、returnみたいにif-expressionの方に結果を返したい時ってどうすればいいの？

**デフォルトの名無しさん** · 2023/02/09(木) 16:22:54.26

>>449
早期returnはやめましょうルールは完璧に守られる保証があると？

**デフォルトの名無しさん** · 2023/02/09(木) 16:24:27.43

>>451
擬似コードでいいのでイメージを書いてくれ
でないと言いたいことが分からない

**デフォルトの名無しさん** · 2023/02/09(木) 16:25:56.79

>>451
最近入ったラベル付きブロックでbreak

https://rust-lang.github.io/rfcs/2046-label-break-value.html

**デフォルトの名無しさん** · 2023/02/09(木) 16:36:32.32

言語仕様的に可能でも規則で縛ることで安全を担保しようという方法は
いずれ失敗するからそういう要素は必ず言語側の仕様で保証すべき、というのがRustの思想なんだから
「あれは危険だから駄目、コーディング規則で縛る」という発想自体が間違ってる

**デフォルトの名無しさん** · 2023/02/09(木) 16:43:33.27

>>448
リソースが１つだけならいいかも知れないけど複数リソースが絡んでたりすると色々ややこしいコードになっちゃう
>>452
コードレビュー時に return 検索したら

**デフォルトの名無しさん** · 2023/02/09(木) 16:44:45.59

>>450
>>439 に言ってくれ

**デフォルトの名無しさん** · 2023/02/09(木) 16:48:27.59

>>456
なるほど
そういう方法だけに頼ってるなら早期returnのほうが見つけやすいわな

**デフォルトの名無しさん** · 2023/02/09(木) 16:49:18.29

こういうやつ？
let result = 'found: {
　for i in 0..100 {
　　if f(i) {
　　　break 'found Some(i);
　　}
　}
　None
};

**デフォルトの名無しさん** · 2023/02/09(木) 17:15:30.09

>>453-454
>>459
やりたかったのこれだ、せんきゅー！

**デフォルトの名無しさん** · 2023/02/09(木) 17:27:44.71

最近はCでもcleanup属性というのが使えるんだな

**はちみつ餃子** ◆8X2XSCHEME · 2023/02/09(木) 17:43:07.29

>>444
構造化が重要視された時代がある。
順次・反復・分岐によって処理の流れを構築するという点から見ると
早期リターンは流れをすっとばして大ジャンプしてることになるので
コードを追うのを難しくすると考えられていた。
「出入口はひとつずつ」は基本思想だったんだよ。
構造化が不十分だった時代にまず構造化することが大事だったという話。

今では構造化が当たり前になったから次の段階として順次・反復・分岐という構造だけでは
上手く扱いづらい部分をどうやるのがいいのかという模索が続いてるわけ。

**デフォルトの名無しさん** · 2023/02/09(木) 18:03:17.12

戻るgotoは結局なんらかのループを表しているので
Rustならラベル付loopに指定continueで表せる
進むgotoは無制限ではなくラベル指定breakの大域脱出型に制限される
という認識で合ってる？

**デフォルトの名無しさん** · 2023/02/09(木) 18:18:38.11

>>454
なんか微妙な機能だな
関数化して早期returnさせる手間が嫌ということなんだろうけどそれなら||や&&オペレータをOptionやResult用に上書きできるようにした方がずっと使いやすい
tryブロックとの非対称性も気になる

**デフォルトの名無しさん** · 2023/02/09(木) 18:30:28.03

>>464
今までに既にあった機能のラベル付loop式のラベル指定breakという使われ方のうち
ループしない使われ方が多かったため事実上のシンタックスシュガーが導入されただけだよ
だから微妙な機能が追加されたという見方は正しくない

**デフォルトの名無しさん** · 2023/02/09(木) 18:30:33.67

>>464
ほとんどの場合はこんなん使う前にその部分を関数に切り出すことを考えるべきというのはめちゃくちゃ言われてる
awaitとかResultとかライフタイムとかいろいろ絡んできたときに再利用もされない数行の処理のために長々と型を書かなくても済むのがユースケースのひとつと思われる

**デフォルトの名無しさん** · 2023/02/09(木) 18:46:56.04

>>465
シンタックスシュガーも機能やろがい
公式にもlanguage featureと書いてるぞい

**デフォルトの名無しさん** · 2023/02/09(木) 18:50:34.43

どうせなら仮変数みたいな変数割当機能も用意して、末尾最適化再帰風ループもできるようにならないかね。

**デフォルトの名無しさん** · 2023/02/09(木) 18:53:10.62

>>467
既に昔から存在していたloop式を
loopと書かなくてもよくなっただけだよ
今までは皆はloop式の最後をbreakすることでloopさせずにこの同じ機能を使っていた
今回でloopを省けるようになったため最後のbreakが不要とだけにすぎない
今さら文句をつけるのが不思議

**デフォルトの名無しさん** · 2023/02/09(木) 19:02:26.27

早期returnってファウラーのガード節の話じゃないん？
あの使い方する限り安全安心可読性改良にしかならないよな？

**デフォルトの名無しさん** · 2023/02/09(木) 19:04:01.20

>>470
ファウラーじゃなくてリーダブルコード？

**デフォルトの名無しさん** · 2023/02/09(木) 19:05:50.10

リーダブルコードは忘れたけど

part of martinfowler.com
https://refactoring.com/catalog/replaceNestedConditionalWithGuardClauses.html

**デフォルトの名無しさん** · 2023/02/09(木) 19:15:02.58

if letでネストが深くならないように早期return等しようとすると無駄コードが膨らんでいた問題も
同時に導入されたlet elseによって解決されたね

**デフォルトの名無しさん** · 2023/02/09(木) 19:24:14.80

>>472
そうこれ、というか第1版からあるならファウラーが先なのね
失礼した

**デフォルトの名無しさん** · 2023/02/09(木) 19:31:22.46

「ルールだからダメ(思考停止)」な人って結構いるよね

**デフォルトの名無しさん** · 2023/02/09(木) 19:40:55.17

ルールの背景を考えずに破ろうとするやつも多いけどな。

守破離は基本だろ。ブルースリーのパンチキックの逸話でもいいけど。

**デフォルトの名無しさん** · 2023/02/09(木) 19:47:18.19

>>476
合理的なロジックがないという点で同類じゃね
「ルールだから問題ない(思考停止)」で他人に迷惑をかけるのも同じ
そして多くの場合無責任までセットだ

**デフォルトの名無しさん** · 2023/02/09(木) 19:54:21.56

そもそも失敗できなくするのがここ10年ぐらいのトレンドだろ。
だから静的型やRustが支持されるわけで。

**デフォルトの名無しさん** · 2023/02/09(木) 20:07:33.02

>>477
ルールについては「決定と実行の分離」という重要な側面があるよ。

頭のいい奴がルールを作れば、アホがルール通りに実行しても被害は少ない。アホがルールを破るよりよほどマシ。

**デフォルトの名無しさん** · 2023/02/09(木) 20:20:31.75

Rustの制御構文としては
昨年末の2つの追加で
従来は不便で需要が多かった形が無事に解決したから一段落かな

**デフォルトの名無しさん** · 2023/02/09(木) 22:05:48.35

>>464
わかる
旧世代言語のニオイがする

**デフォルトの名無しさん** · 2023/02/09(木) 22:51:32.40

こういうの書くやつが出るから
基本は使わないほうがよさそうだな
https://github.com/rust-lang/rust/issues/48594/partials/load_more#issuecomment-1184213006

**デフォルトの名無しさん** · 2023/02/09(木) 23:06:57.24

草
何らかの目的で大域脱出を用意すると必ず妙ちくりんな悪用を考える奴が出てくるんだよな

**はちみつ餃子** ◆8X2XSCHEME · 2023/02/09(木) 23:22:20.06

そういえばコンテナのイテレーションの順序が未規定なときに
順序に依存したコードを書かないように乱数でわざとデタラメな順序にしたら
乱数生成器として使うやつが出てきたって話があったな。

どんな機能も下手に使ったら無茶苦茶にしうるってのはもうどうしようもなくない？

**デフォルトの名無しさん** · 2023/02/09(木) 23:42:25.26

>>56のが実現したらRFCの例は||で代替可
let result = (first_container.iter().find(|&&v| v > 0)
|| second_container.iter().find(|&&v| v < 0))
.unwrap_or(&0);

labelやbreakの手続き的なやり方よりこっちの方が汎用性も高いしrustの目指すべき方向に合ってると思う

**デフォルトの名無しさん** · 2023/02/10(金) 01:49:50.47

メソッド抽出は嫌
クロージャの即時実行も嫌
ラベル付きbreakならOK！
って感覚が俺には理解できんが
ニーズがあるならいいんじゃね

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

>>486
関数切り出しやIIFEだと式の値はResult型になるようなところで、
ラベル付きブロックだとエラーまわりは親の関数に完全に任せて該当の式の値を生で返せる

**デフォルトの名無しさん** · 2023/02/10(金) 02:35:52.13

ラベルでジャンプより、関数の入れ子の方が分かりやすくない？

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

>>487
？オペレータ使えばいいだけなんだが？
逆にエラーまわりだけ親関数に任せるとかヤバくね？