Rust part9

**デフォルトの名無しさん** · 2020/08/23(日) 01:07:35.52

Mozilla発のRust言語のスレ

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

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

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

**デフォルトの名無しさん** · 2020/12/29(火) 23:35:14.28

>>522
昔より増えたapiとimplを分離したクレートは

自分のプロジェクト->api->impl->implが依存するcrate(s)->...

と直列に依存してる。log,slog,serde,thiserror,webrender(etc.)
それに直列に依存するかどうかよりcargoもrustcのフロントエンドもまだ並列化対応が部分的でコンパイル単位の粒度が大きいのが並列ビルドの妨げになるでしょ。

>>526
CIはたしかにキャッシュが効けばいいけど、アナライザの話なら初回しかやらないことはないよ。
アナライザの場合は解析結果が無効になるたびに起きる。
intellij rustはプロジェクト開くたびにやってるし。
JDTみたいにon the fly analyzeするとソースコード変更するたびに解析するから依存グラフは使い回せても他は都度、解析する必要がある。

**デフォルトの名無しさん** · 2020/12/30(水) 00:32:35.13

>>527
言葉足らずですまん
(解析結果をメモリ上にしか持たない設計だから起動時に解析を全部やり直す)rust-analyzerの起動時間が気になるくらい(がコンパイル時間に関して気になる点)
と言いたかった

**デフォルトの名無しさん** · 2021/01/01(金) 09:10:16.97

#![feature(min_const_generics)]だけじゃなく#![feature(const_generics)]も2021に入って欲しいな

**デフォルトの名無しさん** · 2021/01/01(金) 12:06:39.72

全く話は変わるけど、メモリ不足で Box::new に失敗したら、panicが起きて
プログラムがそこで停止するだけ？

**デフォルトの名無しさん** · 2021/01/01(金) 12:08:13.77

>>530
仮にそうだとすると、Cのmalloc()やC++のnew TYPEに比べるとエラー処理は
省ける反面、エラー処理を書きたくてもかけないね。
まあ、滅多に起きないので書いてもしょうがないけれども。

**デフォルトの名無しさん** · 2021/01/01(金) 12:36:28.83

*C++
TYPE *ptr = new TYPE; //メモリ不足の場合ptrにはNULLが返される。
*Java
TYPE obj = new TYPE; //メモリ不足の場合例外がthrowされる。
*Rust
Box<T> obj = Box<T>::new(T()); //メモリ不足の場合panicが生じアプリがダウンする。

Rustは、高度な安全性を要する分野や組み込みでは困るかも。
それに記述が長い。

**デフォルトの名無しさん** · 2021/01/01(金) 12:40:33.89

C++のnewはメモリ不足のとき通常は例外が送出されるぞ
メモリ不足でnullptrを返すにはnew(nothrow)にしないといけない

**デフォルトの名無しさん** · 2021/01/01(金) 12:54:35.66

>>533
昔、
TYPE *ptr;
if ( (ptr = new TYPE) == NULL ) {
　printf( "Memory allocation erro has occured.\n" );
}
みたいに書いていたことがあるけど、これは昔のC++でも間違っていたのだろうか？

**デフォルトの名無しさん** · 2021/01/01(金) 12:57:46.63

Javaは、例外をthrowする関数を呼び出した場合、必ずtryブロックで囲むか、
または、呼び出しもとの関数の宣言の最後にthrow/throws属性をつけるかしないと
いけないんだけど、なぜかnew演算子の場合だけはこの規則の例外で、
tryブロックで囲むこともthrow/throws属性を付ける必要も無いらしい。
ただし、tryブロックで囲んでcatch文でOutOfMemoryErrorという例外を
捉えることは出来るらしい。
意外と良く考えられていて、便利そう。

**デフォルトの名無しさん** · 2021/01/01(金) 17:48:44.20

検査例外等も知らない人が言語仕様にケチつけるなよ

**デフォルトの名無しさん** · 2021/01/01(金) 18:19:22.53

知識が無くてもそれが使いにくいことが分かる人もいれば、
知識があってもそれが使いにくいことが分からない人もいる。
その差はイマジネーションや経験や頭の良さの差。

**デフォルトの名無しさん** · 2021/01/01(金) 19:06:09.23

知識も経験もイマジネーションも頭の良さもない
お前さんどうすんの？

**デフォルトの名無しさん** · 2021/01/01(金) 19:06:27.88

20年以上前？のC++だとNULLが返ってきてたみたいだな
C++98の頃には例外が投げられてる

**デフォルトの名無しさん** · 2021/01/01(金) 19:07:24.81

出た、”地頭”信者ｗ

**デフォルトの名無しさん** · 2021/01/01(金) 19:20:38.81

Rustのpanicはスレッド単位ですよ

**デフォルトの名無しさん** · 2021/01/01(金) 19:55:37.74

プラットフォームにもよるのでは
panic=abort
しかない環境もある

**デフォルトの名無しさん** · 2021/01/01(金) 22:11:27.78

かなり初歩的な質問で申し訳ないんだけど、例えばHashMapをイテレータで舐めてるときに内部でそのHashMapを更新したいときはどうするのがベストなの？
例えば次のようなケースではどうすれば……

https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=f6c554ab761450881f28e48faa55bf8c
use std::collections::HashMap;
fn main() {
let mut map: HashMap<_, _> = HashMap::new();
for i in -5..=5 {
map.insert(i, i);
}

for (key, value) in map.iter() {
if *value == 0 {
continue;
}
if let Some(another_value) = map.get_mut(&(-key)) {
// keyの絶対値が同じものを処理して、処理済みにする気持ち
*another_value = 0;
}
}
}

**デフォルトの名無しさん** · 2021/01/02(土) 00:25:45.81

>>543
map.iter() を map.iter().cloned().collect::<Vec<_>>() にする

**デフォルトの名無しさん** · 2021/01/02(土) 00:53:14.75

keyの絶対値が同じものでgroupingしてからイテレート

**デフォルトの名無しさん** · 2021/01/02(土) 02:08:00.06

rust的にはそういうことしないのがベストじゃない
俺だったらキーだけ取り出してループさせる

**デフォルトの名無しさん** · 2021/01/02(土) 09:20:56.29

>>544-546
ありがとう！
しかしRust的には褒められたやり方じゃないんだね
LL言語脳から切り替えないといけないなあ

**デフォルトの名無しさん** · 2021/01/02(土) 14:15:48.62

逆に-keyで絶対値にする言語とかあんの？
Rustではkey.abs()だぞ

> keyの絶対値が同じものでgroupingしてからイテレート
ソース見る限り元キーはそのままで{-1: 0, 1: 0}みたいにしたそうだからグルーピングでは絶対値にキー統一されるからダメだね

**デフォルトの名無しさん** · 2021/01/02(土) 15:20:56.88

>>543
イテレータを回してるときに内部でそのcollectionをいじくる一般的な方法を聞きたかっただけで、そのコードはただ説明のためのモックなのでコードの妥当性とかはどうか気にしないでください……

**デフォルトの名無しさん** · 2021/01/02(土) 16:10:45.39

これは個人的な解釈だけど、ループ中にコレクションをイジるのを許可すると要素の追加削除も許可されるので、動作が想定しにくいから言語に関わらずやるべきじゃないと思う

**デフォルトの名無しさん** · 2021/01/02(土) 17:40:37.90

有名なアルゴリズムでも破壊的に処理を進める物は少なくないから
それらをリソースを押さえたままより安全に実装するかという問題はある

**デフォルトの名無しさん** · 2021/01/02(土) 20:33:28.09

単純に破壊的操作とイテレータの組み合わせが良くないんだと思うけどね
基本的なアルゴリズムの実装でならC++でも大抵インデックスアクセスするし

**デフォルトの名無しさん** · 2021/01/03(日) 01:40:10.34

絶対値で比較されるようなkeyの型を用意してBtreeMapにぶちこんでiter_mut()すれば
絶対値が同じキー同士は連続して現れるからうまいことやればやりたいことはできるのでは
コード複雑になりそうだけど

**デフォルトの名無しさん** · 2021/01/03(日) 02:42:58.53

>>550
C++狂い「安全性よりも論理的、数学的に正しいかが重要」

**デフォルトの名無しさん** · 2021/01/03(日) 15:16:13.09

Rustで大量の敵が同時に出現する2Dゲームを作ろうと考えています。
Amethyst、ggez、Bevyの中で最もおすすめのゲームエンジンはどれでしょうか？

**デフォルトの名無しさん** · 2021/01/03(日) 15:58:43.30

イニダン亡き後の移住先か…！

**デフォルトの名無しさん** · 2021/01/03(日) 17:51:55.22

スライムが5000匹現れた！

**デフォルトの名無しさん** · 2021/01/03(日) 20:23:57.03

>>552
まあ通常そういう場合はint値でモロにインデックスアクセスするわな。
これがrustとは全く馴染まない。

**デフォルトの名無しさん** · 2021/01/03(日) 21:45:20.19

single writer or multiple readerのモデルに沿うようなロジックに変換するか
interior mutabilityを使うかのどちらか

**デフォルトの名無しさん** · 2021/01/05(火) 22:41:10.79

>>555
個人的にはAmethyst。
なぜなら俺が個人的にECSアーキテクチャが大好きだから。
小さなプロジェクトに向かないとか言われるけど知らないそんなの。

**デフォルトの名無しさん** · 2021/01/05(火) 23:32:43.62

RustでTDみたいなブラウザゲー作った猛者おりゅ？

**デフォルトの名無しさん** · 2021/01/08(金) 08:35:58.68

なんでこんなゴミを100M単位でボコボコダウンロードせなならんのや

ゴミ

**デフォルトの名無しさん** · 2021/01/09(土) 00:36:27.01

>>562
それって回線がゴミなだけじゃ...

**デフォルトの名無しさん** · 2021/01/10(日) 12:11:15.45

評価順序のルールがよくわからないんですが、
タプル生成のときの呼出し順序って保証がありますか？
つまり

(foo(), bar())

みたいに書いたときに foo が常に先に呼ばれることは保証されますか？

**デフォルトの名無しさん** · 2021/01/10(日) 13:02:46.89

保証されてるんじゃない？
でも呼び出し順が重要なら行を分けて書いてからtupleに入れたほうがいいような気もする

The meaning of each kind of expression dictates several things:
・Whether or not to evaluate the sub-expressions when evaluating the expression
・The order in which to evaluate the sub-expressions
・How to combine the sub-expressions' values to obtain the value of the expression
https://doc.rust-lang.org/reference/expressions.html

**デフォルトの名無しさん** · 2021/01/10(日) 15:22:53.59

評価順序についてはもう少しわかりやすくリファレンスを更新する予定みたい
https://github.com/rust-lang/reference/blob/964dc5bab5f7418aea36233c271ceedaea216598/src/expressions.md#evaluation-order-of-operands
https://github.com/rust-lang/reference/pull/888/

**デフォルトの名無しさん** · 2021/01/10(日) 15:34:43.17

>>565-566
ありがとうございます。
無学なので少し書き方が分かりやすくなっても英語だとしんどい……。

**デフォルトの名無しさん** · 2021/01/11(月) 14:09:54.51

ファイル (またはネットワーク) から得られる所定の書式のレコードの繰り返しを
イテレータとして抽象化したいと考えました。
(ちなみにレコードの繰り返しの前にレコードの個数を含むヘッダもあります。)

しかし IO はエラーの可能性があります。
書式の仕様に違反する入力になっている可能性もあります。

イテレータが返す型を Option<Result<要素の型,エラーの型>> としてしまうと
エラーの時点で終端という扱いにならないので様々なメソッドと組み合わせ難いですし、
Result を挟まないとエラーの内容を返せないのでハンドリングしづらいです。

何か綺麗にやれるイディオムのようなものがあったりしませんか？

**デフォルトの名無しさん** · 2021/01/11(月) 15:21:23.54

エラーの時点で終端にするかどうかは呼び出し側が決めることじゃない？
Option<Result<T, E>>もResult<Option<T>, E>もイディオムとしてよく使われてる

**デフォルトの名無しさん** · 2021/01/11(月) 15:47:03.74

>>569
出来るか出来ないかで言えば出来るし好きにすれば良い話ではあるんですが、
標準で良いされている様々なメソッド (たとえば map のような基本的なメソッドさえ！)
と「組み合わせ難い」ということが綺麗じゃないなぁという気持ちなんですが、
そこらへんの不格好さは許容するしかない雰囲気ということでしょうか？

(通常の終端に到達するのとは別に) 中断を表現する方法があって
中断の理由を伝播するのに便利な語彙を詰め込んだクレートがあったりすると
助かるんですが。

**デフォルトの名無しさん** · 2021/01/11(月) 16:05:22.66

>>570
公式にあるイディオムっぽいのはこれとか。
https://doc.rust-lang.org/rust-by-example/error/iter_result.html

クレートは探すと色々見つかるけど、結局「便利な」ってのが人それぞれだし、あまり流行ってる感じはしないな。
むしろその中断表現をうまくやるアイデアがあるなら自分で作ったほうがいいのでは。

**デフォルトの名無しさん** · 2021/01/11(月) 16:41:17.67

>>570
組み合わせ難いと言ってる内容をコードで示してくれないとなんとも

**デフォルトの名無しさん** · 2021/01/11(月) 20:34:05.33

イテレータとして抽象化したいってどういう意味なの
Iteratorをimplするってことなのかしら

**デフォルトの名無しさん** · 2021/01/11(月) 23:06:51.09

>>573
ここでいう「イテレータとして」というのは std::iter::Iterator に限るわけではなく、
繰り返しを表現する何らかの型定義と思ってください。
適当なクレートがあるならそれでいいですし、考え方だけでもいいです。

欲しい機能をあらためてまとめると

・繰り返しに (終端に到達する以外の) 中断の方法が用意されている
・中断したときに中断の理由 (エラー型の値) を伝える方法がある

なのですが、
std::iter::Iterator だと next が返す Option<Result<T, E>> でエラーのときに
「中断」しようとすると for 文の中で break する書き方くらいしか思いつかず、
自分で便利なものを作ろうにもどう作れば便利になるのかも
想像がつかないのです。

**デフォルトの名無しさん** · 2021/01/12(火) 02:11:34.65

>>574
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=aaf882f54a7b6330ee6ad2106be92717
こんな感じでscan使えばNoneを返したところで
イテレーションを中断できるしErrの値も列挙できる

**デフォルトの名無しさん** · 2021/01/12(火) 02:12:25.76

中断するだけなら take_while 使うという手もある

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

俺もtake_whileを思い浮かべたけど関数を作るわけじゃないんでしょ
ゴールがいまいちみえないからイメージでいいのでコードで用件を示してほしい

**デフォルトの名無しさん** · 2021/01/12(火) 11:44:28.63

単にエラー返して中断したいだけならResultにcollectしたりtry_for_eachで消費すればいいよ
イテレータアダプターとしてエラーも含めて列挙しつつ次につなげたいなら>>575が書いてるscanやtake_while系
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=113dcf689b4d941c89e714ebb1414958

**デフォルトの名無しさん** · 2021/01/12(火) 20:39:12.01

AsRefトレイト使ってenumから&str返すのっておかしい？
Display実装で文字返してたらアロケートされるからAsRef使おうと思ってるんだけど

**デフォルトの名無しさん** · 2021/01/12(火) 20:51:33.48

Rustの利用状況調査、ビジネス利用が進む一方で習得の難しさなどが依然課題
https://www.atmarkit.co.jp/ait/articles/2101/12/news046.html

**デフォルトの名無しさん** · 2021/01/12(火) 21:41:00.77

>>579
AsRef に拘らず独立した as_str 用意した方が良いと思う

**デフォルトの名無しさん** · 2021/01/12(火) 22:42:54.02

AsPath が AsRef<Path> になった過去もあるから汎用性持たしてas_str実装するよりAsRefで実装する方がいいといいと思うけど他の人はどう思う？

**デフォルトの名無しさん** · 2021/01/12(火) 23:59:44.33

as_strに一票

**デフォルトの名無しさん** · 2021/01/13(水) 08:49:31.39

自分で使う、as_str
ライブラリとして他で使われる、AsRef

**デフォルトの名無しさん** · 2021/01/13(水) 09:22:05.24

>>580
学習難度はまず低級言語と高級言語両方の利点欠点を理解しないと良さが理解出来ないからねえ…
設計思想からして中上級者向けだから仕方ないかも

**デフォルトの名無しさん** · 2021/01/13(水) 10:55:46.25

単に学習難易度が高いだけでなく、学習が済んだ後もこの言語はめんどくさいが、
C++よりもむしろ。

**デフォルトの名無しさん** · 2021/01/13(水) 12:45:22.11

>>582
AsRefはIntoOwnedと対になっていて str<->String Path<->PathBuf みたいな ref/owned 関係にあるもの同士の変換に使うものだと思う
enum -> &str はそういう関係にはないので微妙に思う

**デフォルトの名無しさん** · 2021/01/13(水) 13:36:01.48

>>586
風俗で事が済んだ後で説教始めるオッサンみたい

**デフォルトの名無しさん** · 2021/01/13(水) 13:53:35.67

C++とRustで難しさめんどくささの方向性違うしな
好みの範疇だと思ってる

**デフォルトの名無しさん** · 2021/01/13(水) 21:18:34.66

Rustのめんどくさいところはダントツでクレート関係だよな
標準で入ってないかつ、細かすぎるからコンパイル糞長いし、APIの仕様が統一されてないからドキュメント見ないと話にならんとこ
しかもクレートによっちゃライフタイム絡ませてきてめちゃくちゃになるし
C++はとにかく言語仕様のいらない豊富さが嫌気さす

**デフォルトの名無しさん** · 2021/01/13(水) 21:41:40.93

D言語かDelphiやれ

**デフォルトの名無しさん** · 2021/01/13(水) 23:05:33.49

もう.net5とC#でいいやん

**デフォルトの名無しさん** · 2021/01/14(木) 01:15:26.66

>>590
traitのおかげで他と比べるとAPIの統一性は達成されてるようにおもう

**デフォルトの名無しさん** · 2021/01/14(木) 01:57:39.37

クレートいいと思うけどな
標準ライブラリに入れると破壊的変更できなくなるけどクレートなら古いバージョン使うことも出来るから
気兼ねなくライブラリを進化させることが出来る

**デフォルトの名無しさん** · 2021/01/14(木) 08:51:13.78

pure-Rustのクレートなら今のところ確実にコンパイルは通るしな。
C++だとGitHubから拾ってきたライブラリが手元でコンパイル通るかどうか半々って感じで厳しい。
マイナーなディストリビューションのせいではあるけど、全部Ubuntuに統一というわけにもいかんしなぁ。

**デフォルトの名無しさん** · 2021/01/15(金) 20:23:33.58

struct A;
struct A();
これとこれが定義できる理由ってなんかある?

struct A {};
だけで済むし、記述バラバラになるから統一したいんだけど

**デフォルトの名無しさん** · 2021/01/16(土) 00:28:37.68

Rustが一番めんどくさいのはメモリ管理だな。
というよりメモリ管理の事ばかり気にしてプログラムしなくてはならない。
plain CやC++ではそこまで気にしなくて良い。

**デフォルトの名無しさん** · 2021/01/16(土) 01:28:58.93

？？？？？？？？？

**デフォルトの名無しさん** · 2021/01/16(土) 11:40:00.74

いつものやつだ気にするな

**デフォルトの名無しさん** · 2021/01/16(土) 14:07:27.84

結局メモリを気にする言語にへんな暗黙性を入れるのは失敗ってことだな。

**デフォルトの名無しさん** · 2021/01/21(木) 02:51:30.26

Rust で書いたツールにドキュメントを付けようとしています。
ライブラリのドキュメントではなくツールとしての使い方の詳細で、
readme に書くには大きすぎるような文章です。

cargo.toml では package.documentation でドキュメントの場所を URL で
示すことは出来るようですが、パッケージ内にドキュメントを一緒に入れておいて
cargo install で適当なところにインストールするようなことは出来ないのでしょうか？

あるいは cargo の直接の管理下には入れられないにしても
なんらかの習慣があったりしますか？

**デフォルトの名無しさん** · 2021/01/21(木) 07:00:10.04

ゴミ言語

**デフォルトの名無しさん** · 2021/01/21(木) 14:31:58.28

manみたいにドキュメントインストールする方法は知らないな。
ローカルにインストールしなくてもリポジトリのwikiあたりに使い方書いておいてそれ見てねでいいんじゃないかとおもうけど。

**デフォルトの名無しさん** · 2021/01/21(木) 21:40:35.33

ビルドスクリプト使ってenv::var("OUT_DIR”)で取得できるパスにファイル出力してるのが多いみたい

**601** · 2021/01/21(木) 22:18:23.22

なるほど。そういうやり方もあるんですね。
でもドキュメントを各環境で適切な場所に
インストールするのは結局は手作業ということになりそうですね。

そういうことなら無理に自動化するのは諦めて
必要ならこのディレクトリで mdbook コマンドを実行してねみたいな感じにした方がかえって楽かな……

**デフォルトの名無しさん** · 2021/01/21(木) 22:42:45.36

cargo installでrustバイナリ以外をインストールするオフィシャルの方法は長年用意されてないから別の手段で頑張るしかない
https://github.com/rust-lang/cargo/issues/2729

**デフォルトの名無しさん** · 2021/01/24(日) 00:35:05.68

fn num() -> usize {
10.pow(9)
}
この定数はなぜ推論でusizeにならないんですか？

**デフォルトの名無しさん** · 2021/01/24(日) 19:33:54.83

もういい加減にしてクレート

**デフォルトの名無しさん** · 2021/02/03(水) 05:50:55.51

なんでいちいちゴミをワサワサDLしなきゃならねーんだよゴミ言語

**デフォルトの名無しさん** · 2021/02/03(水) 21:58:38.43

どしたのわさわさ

**デフォルトの名無しさん** · 2021/02/03(水) 22:30:52.82

DustじゃなくRustだからゴミじゃなくてサビ言語だよ

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

&strってなんで&Stringじゃないの？

**デフォルトの名無しさん** · 2021/02/04(木) 20:19:37.24

その2つは別のもの
どっちも存在する

&strはstring sliceのborrow
&StringはStringのborrow

**デフォルトの名無しさん** · 2021/02/04(木) 20:39:25.16

>>613
同一だと思ってたけど違うの？？

&strを要求する関数とかメソッドに&String渡しても動くもんだからてっきり

**デフォルトの名無しさん** · 2021/02/04(木) 20:54:06.40

それはDerefの効能

**デフォルトの名無しさん** · 2021/02/04(木) 21:06:19.09

&strはStringの一部か全部へ参照 rust的にはスライスへの参照
&string[1..3] こういうこと

引数を&StringにするのStringの参照しか渡せないが、&strにすればStringの一部や””で囲った&strも渡せる

**デフォルトの名無しさん** · 2021/02/05(金) 01:36:04.17

>>614
引数として&strをとるメソッドや関数に&Stringは渡せないんじゃなかったっけ
self の場合の話？

**デフォルトの名無しさん** · 2021/02/05(金) 01:46:13.57

>>617
StringはDeref<Target=str>を実装してるから&strをとる関数に&String渡せる
https://doc.rust-lang.org/std/string/struct.String.html#deref

**デフォルトの名無しさん** · 2021/02/05(金) 13:26:40.93

こういう暗黙変換て混乱を生むだけだと思う。

**デフォルトの名無しさん** · 2021/02/05(金) 15:35:15.48

>>618
二つ目の例だけ記憶してて勘違いしてたみたい。ありがとう

>>619
rustは暗黙変換かなり少ないからマシな方だと思う
メソッドのselfの暗黙変換はないとつらいかと

**デフォルトの名無しさん** · 2021/02/06(土) 16:00:13.52

Option::filterのResult版って無いのかな？

**デフォルトの名無しさん** · 2021/02/06(土) 20:10:46.18

>>621
条件に合致しない場合は何を返して欲しいの？

**デフォルトの名無しさん** · 2021/02/06(土) 21:49:40.07

>>621
and_thenでErr返せば？

**デフォルトの名無しさん** · 2021/02/06(土) 21:55:40.99

>>622
引数で渡したエラー値をErrにくるんで返してほしい

**621** · 2021/02/07(日) 10:23:42.94

>>623
うん、それが最適でしたね

もともとTと&T -> boolからOption<T>を構築してたコードがあってSome(t).filter(|t| !t.is_hoge())ってしてたんだけど
それをResultに変えようとしたらif式で数行増えちゃって
ちょうど対応するようなのって無いのかな？って思って質問した次第でした

**デフォルトの名無しさん** · 2021/02/07(日) 11:40:55.51

それはok_orかok_or_elseで変換すればいいだけじゃなくて？