Rust part15

**デフォルトの名無しさん** · 2022/05/12(木) 18:28:20.99

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

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

日本語の情報
https://rust-jp.rs/

※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/

※C++との比較は専用スレへ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

※次スレは原則>>980が立てること

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

**デフォルトの名無しさん** · 2022/05/22(日) 14:14:17.72

servoはまだ実験段階だったと思う

**デフォルトの名無しさん** · 2022/05/22(日) 14:54:56.44

>>273
ありがとう～

**デフォルトの名無しさん** · 2022/05/22(日) 15:29:45.38

>>270
特にそういう予定はないと思う
servo自体も別に次世代Firefoxを目指してるとかではなく、Rustでwebブラウザを書く実験プロジェクトという感じ
その実験でうまく行ったコンポーネントを徐々にFirefoxに移植していっている

**デフォルトの名無しさん** · 2022/05/22(日) 15:57:34.13

アプローチとしては正しい姿なんだろうな

**デフォルトの名無しさん** · 2022/05/22(日) 17:29:35.11

暇を持て余した神々の遊び

servoと言うよりモンスターエンジンだね…

**デフォルトの名無しさん** · 2022/05/22(日) 17:37:14.17

>>270
C++で書かれてる部分は置き換えられるかも知れないけどJSで書かれてる部分までは置き換えしないんでないかな

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

JSとか言ってるのは君だけだと思うよ

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

>>280
FirefoxではC++と同じくらいJS使われてるよ
https://www.openhub.net/p/firefox/analyses/latest/languages_summary

**デフォルトの名無しさん** · 2022/05/22(日) 19:25:56.61

JSの部分を置き換えるなんてはなから誰も思ってないってことだと思うが

**デフォルトの名無しさん** · 2022/05/22(日) 19:26:01.69

意訳すると「JSで書かれてる部分まで置き換えるとか言ってるのは君だけだと思うよ」かな？
言ってないね

**デフォルトの名無しさん** · 2022/05/22(日) 19:29:03.65

>>282
正解

>>283
アホ
JSで書かれてる部分まで置き換えるかどうかとか言ってるのは君だけだと思うよ

**デフォルトの名無しさん** · 2022/05/22(日) 19:33:12.87

>>284
じゃ>>280で「言ってる」とか書くな
ボケ

**デフォルトの名無しさん** · 2022/05/22(日) 19:46:00.83

>>285
はあ？
JSって言ってるよね？
バカなの？

>>279 JSで書かれてる部分までは置き換えしないんでないかな

**デフォルトの名無しさん** · 2022/05/22(日) 19:56:58.26

>>270 が「Firefox を "丸ごと" 書き換える」と言っていたので全部はRustにならないよと伝えたんだけどなんかお気に召さなかった？

**デフォルトの名無しさん** · 2022/05/22(日) 20:16:58.99

>>270が言うのはservoのことでquantumの動機がcssパーサrustで書いたら
安全だったからC++で書かれたコンポーネント置換しよだからjs出る余地ないじゃん。
>>282で終わった話。

**デフォルトの名無しさん** · 2022/05/22(日) 20:17:09.14

そうだね、そんなふうに言われたらシェルスクリプトやMakefileまでrustで置き換えるんじゃないかって思っちゃうよね。

馬鹿なん？

**デフォルトの名無しさん** · 2022/05/22(日) 20:36:16.46

FirefoxはXULのイメージがあってJSも主要な構成要素だと思ってたから変なレスつけちゃったね
皆さんの機嫌害しちゃって申し訳ない

**デフォルトの名無しさん** · 2022/05/22(日) 20:54:23.92

よく見たらID変えて暴れてるやつまだ居座ってるのか。

>>290
XULはだいぶ前に死んだよ。
XULRunnerが単体で利用困難な問題が解決できなくて存在意義を失った。

**デフォルトの名無しさん** · 2022/05/22(日) 22:32:56.13

>>291
XUL完全になくなったの？
XBLは完全に消えたって聞いたけどXULは細々と生き残ってるものだと思っていた

**デフォルトの名無しさん** · 2022/05/23(月) 01:12:40.07

>>290
ほんと反省しろよ

**デフォルトの名無しさん** · 2022/05/23(月) 02:27:31.54

反省してま～す

**デフォルトの名無しさん** · 2022/05/23(月) 19:27:40.26

>>189
おまえら全員そうだがフィボナッチ数列でusize固定はおかしいだろ
コード自体は問題ないが <T: Zero + One + CheckedAdd> を付けろ
あとは0と1をT::zero()とT::one()へ置き換えればi8型からBigUintまで何でも動作するようになる
https://play.rust-lang.org/?edition=2021&gist=929f3df48db39182558dfad6fe8d1cda

さらに今回はfrom_fn()利用をそのままsuccessors()利用へ変換できるので見やすくなる
fn fibonacci_iter<T: Zero + One + CheckedAdd>() -> impl Iterator<Item = T> {
let mut oq = Some(T::one());
iter::successors(Some(T::zero()), move |p| {
let q = oq.take()?;
oq = q.checked_add(p);
Some(q)
})
}
ちなみにCloneを要求しないためBigIntなどでも無駄なコスト増とならない

>>202
そのコードは暗黙のコピーが発生している
from_fn()使用版のコードはcurrがキャプチャ変数なので「let n = curr?;」でコピー発生
successors()使用版のコードはクロージャ引数「|&curr: &usize|」の「&」でコピー発生
usizeならば問題はないがBigIntなどでそのコードは動かないので劣る

**デフォルトの名無しさん** · 2022/05/23(月) 19:52:54.51

暗黙のコピー発生って気にするべき？
!Copyならコンパイルエラーになるしこれまで気にしたことなかった

あとcurrはmoveでキャプチャされるからcurr?で発生するのはmove(とそれに伴うmemcpy)だけど、moveのコストも気にすべき？

**デフォルトの名無しさん** · 2022/05/23(月) 20:00:24.28

>>296
それは逆
そのキャプチャされた変数はクロージャが呼ばれるたびに何度も使われる
つまりムーブされてはいけない、つまりムーブ禁止となる
したがって n = curr? で currの中身は nへムーブされずコピーとなる

**デフォルトの名無しさん** · 2022/05/23(月) 20:11:34.97

>>297

**デフォルトの名無しさん** · 2022/05/23(月) 20:12:20.25

>>296
必ずCopy前提の型しか扱わないときは気にしなくていい
しかし今回は!Copyの数値型でも動かないと話にならないからコピーが起きるコードを避けないと

**デフォルトの名無しさん** · 2022/05/23(月) 20:19:20.85

>>299
!Copyの場合はコンパイルエラーになるからわざわざ人間が注意を払う必要はないと思うが、気にすべき？
usizeしか使わなくてもTに置き換えた場合を想定してコードを書くべきということ？

**デフォルトの名無しさん** · 2022/05/23(月) 20:27:05.01

>>300
u128を使ってもf(200)がオーバフローするような今回の案件でCopy型が前提のコードはよくない
案件次第だけど今回はコピーの有無を気にすべき案件

**デフォルトの名無しさん** · 2022/05/23(月) 20:43:27.72

>>295
自分のレスに他人のふりしてレスするキチガイ汚コーダーこと複オジさんちぃーすっ

**デフォルトの名無しさん** · 2022/05/23(月) 20:49:26.67

>>296
それはmoveの意味を間違えているぞ
>>202のcurr?はコピーが発生する
FnOnceじゃないんだからcurrの値がmoveされたら次に使えなくなる
move禁止となりCopy型ならコピーが発生し!Copy型ならエラーとなるコード

**デフォルトの名無しさん** · 2022/05/23(月) 21:10:50.44

>>301
copyを気にするのではなくusize or BigIntのどちらを使うべきか意識すべきと解釈した
usizeで良い場合はcopyは気にせずして良い

>>303
FnOnceかFnMutかFnかは関係なくて
moveなclosureでキャプチャしたらmove発生するよ
moveでキャプチャされた値をクロージャの中でさらにmoveできるか、refしかとれないかがFnOnceとFnの違い

**デフォルトの名無しさん** · 2022/05/23(月) 21:18:12.89

https://www.reddit.com/r/rust/comments/3wubj0/comment/cxzlvt4/

num_traitsによるジェネリクスは絶対の正解ではないから適当なところで諦めようね

**デフォルトの名無しさん** · 2022/05/23(月) 21:23:42.08

>>304
それは別の話でその違いを理解できていないようにみえる
クロージャへのmoveはクロージャが作られた時に終っていてクロージャ内のコードでの動作なは関係ない
間違っているのは後者の話でこの部分

>>296
> curr?で発生するのはmove(とそれに伴うmemcpy)

curr?でmoveは起きない
curr?で起きるのはコピーである(!Copy型ならエラー)

**デフォルトの名無しさん** · 2022/05/23(月) 21:33:03.23

>>296
コピーもmoveも同じでそれがボトルネックかどうかが重要
数値プリミティブの場合はコピーを他の方法に変えたところでボトルネックが解消されることはまずないから気にする必要はない

BigUint前提ならVecと同じでmoveやクローンやのオーバーヘッドはそれなりに気にした方がいい
逆に現実的にはオーバーフロー考慮する必要がなくなるからCheckedAddが余計なオーバーヘッドになる

特性の違う物をジェネリック等でまとめたほうがいい場面なのかそれぞれ別の実装を用意したほうがいい場面なのか判断できることが大事

**デフォルトの名無しさん** · 2022/05/23(月) 21:43:43.53

>>307
それは間違ってるぜ
BigUintのchecked_add()は常にSomeを返すためにチェックとSomeは消えてオーバーヘッドとならない
さらにRustのジェネリックは各型にmonomorphizationされるためジェネリックで書いてもプリミティブ型やBigUint型のコードはそれぞれに最適化される

**デフォルトの名無しさん** · 2022/05/23(月) 22:04:52.01

ヒント:
Ratio<T> where T: Integer + Clone + CheckedAdd + CheckedMulは>>295の条件を満たす

**デフォルトの名無しさん** · 2022/05/23(月) 22:25:54.83

fibonacci_iter::<Ratio<u8>>()すると
ちゃんと最後233で止まるのね
ジェネリック凄い

**デフォルトの名無しさん** · 2022/05/23(月) 22:34:47.31

ククク……RatioのCheckedAddの実装を見ても果たして同じことが言えるかな

**デフォルトの名無しさん** · 2022/05/23(月) 22:37:22.49

汚染が始まった！

**デフォルトの名無しさん** · 2022/05/23(月) 22:55:06.68

>>311
たしかにRatioの実装が悪いな
まずAddと同様に
if self.denom == rhs.denom {の分岐をし
そして1の場合は
self.numberとrhs.numberでchecke_addするくらいはしないとな

**デフォルトの名無しさん** · 2022/05/23(月) 23:14:26.50

ジェネリックに書いてもRatio専用コードを書いても
どちらもRatioの実装を使わざるをえないのだから同じ結果となる

そしてRatio専用コードを書こうとしても外部からは工夫のしようがないため
ジェネリックからコンパイル時にモノモーフィゼーションされるコードと全く同じになる

**デフォルトの名無しさん** · 2022/05/23(月) 23:46:45.42

このスレごちゃごちゃした書き込み多すぎ

**デフォルトの名無しさん** · 2022/05/24(火) 00:53:51.91

各型を個別に確認しないと良いか悪いか判断できないならジェネリックにしちゃだめでしょ

**デフォルトの名無しさん** · 2022/05/24(火) 01:46:13.03

>>316
そんな個別に確認しなきゃいけないことは起きないから大丈夫
Rustの標準ライブラリも大半はジェネリックに書かれている

**デフォルトの名無しさん** · 2022/05/24(火) 07:59:54.71

>>307
>特性の違う物をジェネリック等でまとめたほうがいい場面なのかそれぞれ別の実装を用意したほうがいい場面なのか判断できることが大事
禿同だわ
コードパズルやってるやつにいつも感じる違和感の原因はこれだな
こういう能力って何て言うんだろ？

**デフォルトの名無しさん** · 2022/05/24(火) 08:06:11.71

>>318
でも今回の件の数列ならばジェネリックが正解やろな
わざわざ各数値型に個別に実装しなくて済む
分けるほうが不自然で手間

**デフォルトの名無しさん** · 2022/05/24(火) 08:45:23.72

男の人って気持ち悪い…
どうして少女をそんなに汚したがるの？
お母さんに悪いとわおもわないの？

**デフォルトの名無しさん** · 2022/05/24(火) 08:52:13.15

>>318
広く言えば設計能力
狭く言えば実装パターンの選択能力

総合的な能力だから一朝一夕には身に付かない
実装パターンの整理が進んでないRustだと特に

**デフォルトの名無しさん** · 2022/05/24(火) 11:37:27.58

KISS原則だろ

**デフォルトの名無しさん** · 2022/05/24(火) 19:12:35.28

>>202のlet n = curr?;の部分を
>>189はlet n = curr.take()?;としてコピーになるのを回避しているだけかと思ったら
両者が全く異なるアルゴリズムを採用していることに気付いた
>>202のアルゴリズムだとどうやってもコピーを避けられないから詰んでるね

**デフォルトの名無しさん** · 2022/05/24(火) 22:16:43.51

prev, currの状態管理だとcurrの値をprevに代入するのと戻り値として使うのと2箇所に必要になるからね
curr, nextで管理すればいい

**デフォルトの名無しさん** · 2022/05/24(火) 22:24:27.19

アルゴリズムというほど大げさな話ではないだろ
f(n)を求めるnext()が呼ばれた時に

>>189は内部にf(n)とf(n+1)を持っていて、足し算してf(n+2)を作る
そして内部にf(n+1)とf(n+2)を残して、f(n)を返す

>>202は内部にf(n-1)とf(n)を持っていて、足し算してf(n+1)を作る
そして内部にf(n)とf(n+1)を残して、f(n-1)は捨てて、f(n)をコピーして返す
つまりムダ

>>324
同意

**デフォルトの名無しさん** · 2022/05/24(火) 23:52:58.32

フィボナッチ数のような単純な問題でもプログラミングセンスに差が出るものなんだな

**デフォルトの名無しさん** · 2022/05/25(水) 09:34:10.65

>>218
まずはCから始めるのは間違ってない
Cは仕様が小さいからひと通り学ぶのにそんなに時間は掛からないからね

**デフォルトの名無しさん** · 2022/05/25(水) 13:26:51.10

Webシステム中心ならRustとRails どっちを中心に勉強すればいい？

どうせ仕事で使うのPHPとjsだけど

**デフォルトの名無しさん** · 2022/05/25(水) 13:32:36.84

RustでETみたいなのって書けるん?
てかテンプレートはC++みたいに汎用性高いの?
それともC#みたいに適用範囲絞ってる?

**はちみつ餃子** ◆8X2XSCHEME · 2022/05/25(水) 13:40:48.57

>>329
C++ で言うところのテンプレートは Rust には無いよ。ジェネリクスは ML 風の型システムでやってる。
マクロは Lisp 風と言えると思うけどトークンが型付けされてるから Template Haskell とかのほうが近いかもしれない。

**デフォルトの名無しさん** · 2022/05/25(水) 20:05:45.57

なんだじゃあRustだめじゃん。

**デフォルトの名無しさん** · 2022/05/25(水) 20:20:43.79

>>331
むしろC++のテンプレートよりもRustのの方がほとんどの利用方法で便利かつプログラミングしやすく快適になった

**デフォルトの名無しさん** · 2022/05/25(水) 20:47:56.26

>>331
そうだよ。ダメだから君もRustは使わないほうがいい

**デフォルトの名無しさん** · 2022/05/25(水) 21:47:24.60

行列クラスを作って

X += A*(B+C)/D

みたいな演算子の多重定義して、すっきり1式で書くことできますか?

**デフォルトの名無しさん** · 2022/05/25(水) 22:02:04.30

Matrix<Complex> X(2,2 );
Matrix<double> Y(2,2 );

Y << 1., 2.,
3., 5.;

X = (double)(Y^3);

みたいなことrustで書きたい

**デフォルトの名無しさん** · 2022/05/25(水) 22:12:09.13

>>335
もちろんできる
こういうのがほしいんでしょ
https://docs.rs/simple-matrix/latest/simple_matrix/

初心者の題材としては適切そうだから、自分で実装してみてはいかがか

**デフォルトの名無しさん** · 2022/05/25(水) 22:17:54.75

スマソ
X=(Complex)Y^3
だた

**デフォルトの名無しさん** · 2022/05/25(水) 22:26:34.33

>>332
そこんとこ詳しく
解説サイトでもいいけど

**デフォルトの名無しさん** · 2022/05/25(水) 22:36:32.50

とりあえず一度は the book を読め。
根本的な言語デザインが違うからそこだけ抜き出して詳しい説明なんてできないよ

**デフォルトの名無しさん** · 2022/05/26(木) 00:08:48.87

rustてこんなコードも許すんだな

fn main() {
println!("Hello, world!");
main();
}

https://play.rust-lang.org/
でやってみるとスタック溢れて死んだけど一応実行できるのねww

**デフォルトの名無しさん** · 2022/05/26(木) 07:58:26.46

そんなことで草生やすのはおそらくキミひとり
他の人らは真顔でキミの発言を見守ってるよ

**デフォルトの名無しさん** · 2022/05/26(木) 08:48:32.43

>>341
いや、そんなふうに思ってるのはキミひとりだから

**デフォルトの名無しさん** · 2022/05/26(木) 09:21:13.14

エントリポイントであるmainの停止条件のない再帰が
何のerrorもwarningもなくコンパイルできてしまい、
当然スタックオバフロで停止してしまうなんて間抜けすぎると思ったんだけどね
これが先進言語なのか?ww

**デフォルトの名無しさん** · 2022/05/26(木) 09:45:45.88

>>343
最適化したら、ループに変換されて死ななくなるとか？

**デフォルトの名無しさん** · 2022/05/26(木) 10:23:40.75

Go でやってみたら gopls(Language Server)で infinite recursive call って warning が出た
実行できるけど、

runtime: goroutine stack exceeds 1000000000-byte limit

と表示されて強制終了

**デフォルトの名無しさん** · 2022/05/26(木) 10:39:49.31

>>343
警告出るよ

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=2c7c027a6cf5a2e1c065faaad3a63680

warning: function cannot return without recursing

**デフォルトの名無しさん** · 2022/05/26(木) 18:28:21.56

じゃあGoのほうが良いんじゃん。

**デフォルトの名無しさん** · 2022/05/26(木) 19:07:49.07

そこに気づくとはやはり天才か

**デフォルトの名無しさん** · 2022/05/26(木) 19:23:40.54

>>347
RustもGoもどちらもwarningが出る
そして実行するとスタックが溢れて止まる
完全に同じ

**デフォルトの名無しさん** · 2022/05/26(木) 21:03:33.74

草

**デフォルトの名無しさん** · 2022/05/26(木) 21:33:44.65

イキッてスタックを増し続ける再帰を書くのは愚か、まともなら限界値でブレイクする、天才と努力家は末尾再帰でスタックを増やさない

**デフォルトの名無しさん** · 2022/05/26(木) 21:43:27.13

リリースビルドだと最適化されてスタックオーバーフローにならない
loopと同じになる
fn main() {
loop{ println!("Hello, world!"); }
}

**デフォルトの名無しさん** · 2022/05/26(木) 21:45:32.94

あれ？
前にRustは末尾呼び出し最適化はしないって聞いたけど

**デフォルトの名無しさん** · 2022/05/26(木) 21:53:44.25

言語仕様的に最適化を保証してるわけではないというだけでは？
LLVMがある程度やってくれる
https://godbolt.org/z/os9YMfozf

**デフォルトの名無しさん** · 2022/05/26(木) 22:19:48.49

わかりやすい例
確実にスタックが溢れるusize::MAX回の再帰

fn main() {
assert_eq!(usize::MAX, count(usize::MAX));
}

fn count(n: usize) -> usize {
// println!("{:p}", &n);
match n {
0 => 0,
n => 1 + count(n - 1),
}
}

①デバッグモードだとスタックオーバフロー
②リリースモードだと溢れずアサートも通る
③リリースモードでもコメントになっているprintlnの//を外すと最適化されなくなるようでスタックオーバフロー

**デフォルトの名無しさん** · 2022/05/26(木) 22:41:19.49

>>355
わかりやすい？
println入れるとなぜ最適化されなくなるの？

**デフォルトの名無しさん** · 2022/05/26(木) 23:01:45.92

>>356
再帰だと&nは毎回異なる
つまり再帰をループ化する阻害要因

**デフォルトの名無しさん** · 2022/05/26(木) 23:18:51.46

ごめん
n表示だけでもあかんわ
ループ化されず溢れる
調査のために、printよりもっと軽くて最適化で消えない操作、何かないかな

**デフォルトの名無しさん** · 2022/05/27(金) 10:47:17.91

>>358
ターミナルが標準出力に出てきたのを表示するのがボトルネックになってるだろうな
./a.out > /dev/null するか、printlnの代わりにファイル書き込みするのが手っ取り早い

**デフォルトの名無しさん** · 2022/05/27(金) 23:42:23.72

traitでasync fnなメソッドを宣言してはいけない理由を教えてください

**デフォルトの名無しさん** · 2022/05/28(土) 00:48:37.27

https://github.com/rust-lang/rfcs/issues/2739

**デフォルトの名無しさん** · 2022/05/28(土) 18:21:29.07

async fnはsyntax sugarだから例えば以下は同じ

async fn delayed_add(a: i32, b: i32) -> i32 {
sleep(Duration::from_secs(5)).await;
a + b
}

fn delayed_add(a: i32, b: i32) -> impl Future<Output = i32> {
async move {
sleep(Duration::from_secs(5)).await;
a + b
}
}

つまり現在のRustコンパイラではまだimpl Traitを使える場所が限定されているというもっと大きな問題のために今は使えない
GATsなど現在進行中の諸問題が解決すればいずれ使えるようになるはず

**デフォルトの名無しさん** · 2022/05/28(土) 18:34:44.90

現状の対策方法としてはimpl FutureをdynにしてBox::pinして返す

trait Foo {
fn delayed_add(a: i32, b: i32) -> Pin<Box<dyn Future<Output = i32>>>;
}

impl Foo for () {
fn delayed_add(a: i32, b: i32) -> Pin<Box<dyn Future<Output = i32>>> {
Box::pin(async move {
sleep(Duration::from_secs(5)).await;
a + b
})
}
}

fn main() {
block_on(async {
let x = <() as Foo>::delayed_add(1, 2).await;
println!("x = {x}");
});
}

これでtraitにて非同期関数を使える

**デフォルトの名無しさん** · 2022/05/28(土) 18:41:39.92

それを手動で変換するのは面倒かつコードも見にくいので自動変換してくれる#[async_trait]を使えばasync fnと書ける

use async_trait::async_trait;

#[async_trait]
trait Foo {
async fn delayed_add(a: i32, b: i32) -> i32;
}

#[async_trait]
impl Foo for () {
async fn delayed_add(a: i32, b: i32) -> i32 {
sleep(Duration::from_secs(5)).await;
a + b
}
}

**デフォルトの名無しさん** · 2022/05/28(土) 19:10:23.06

おじさん調査お疲れ様でした。

**デフォルトの名無しさん** · 2022/05/28(土) 19:23:54.07

・塩野義製薬が週休3日制導入へ来年4月、副業も解禁
・塩野義製薬が「週休３日」選択可能に　給与は『週休２日の８割』副業や学び直しを支援
・【フォーカス】サタケ／週休３日制　通年導入めざし夏季のみ試行中　交代制で水曜を休日に
・旅館なのに週休3日!?陣屋・若女将の常識を覆した組織改革
・“時代錯誤”から残業ゼロ、週休3日に！　鳥取の不動産会社が
　レガシー企業からDX先進企業になれたワケ
・ネクスウェイ、週休4日制・1日3時間勤務選択できる勤務体系を導入
・日本初「週休4日制度」で、優秀な人材を採用するしくみとは？ ?
　ナレッジソサエティ久田社長に聞いてみた

**デフォルトの名無しさん** · 2022/05/28(土) 20:19:11.57

もう借りまっか

**デフォルトの名無しさん** · 2022/05/28(土) 21:23:09.11

ジェネレーターはいつstableになりますか

**デフォルトの名無しさん** · 2022/05/28(土) 23:09:24.03

stableを期待しているということは現状の仕様で納得なんだろうけど
resumeの仕方とか値の受け取り方とか軽快じゃなくね？

let mut generator = || {
yield 1;
yield 2;
yield 3;
return "end"
};
assert_eq!(GeneratorState::Yielded(1), Pin::new(&mut generator).resume(()));
assert_eq!(GeneratorState::Yielded(2), Pin::new(&mut generator).resume(()));
assert_eq!(GeneratorState::Yielded(3), Pin::new(&mut generator).resume(()));
assert_eq!(GeneratorState::Complete("end"), Pin::new(&mut generator).resume(()));

例えばresume構文を用意して記述を見やすくするとか
return値は廃止してOption<T>で返しreturn;でNoneにするとか

**デフォルトの名無しさん** · 2022/05/28(土) 23:30:01.77

個人的にはIteratorがyield使って実装できるようになれば満足なのでGeneratorそのものの型とかはそんなに気にしてなかった

**デフォルトの名無しさん** · 2022/05/28(土) 23:58:46.72

>>370
yieldを使うとIteratorの実装が楽になる？
from_fn()のようなfrom_generator()を用意するのかな

**デフォルトの名無しさん** · 2022/05/29(日) 01:25:03.17

またイテレータの話してる……

**デフォルトの名無しさん** · 2022/05/29(日) 01:35:28.37

結局イテレータを作るには構造体か何かを用意してnext()実装するしかないぜ
それが面倒ならfrom_fnやunfoldなどの汎用イテレータ作成関数を使うしかないな
こんな感じか

fn iter_from_generator<G: Generator + Unpin>(mut generator: G) -> impl Iterator<Item = G::Yield> {
iter::from_fn(move || {
match Pin::new(&mut generator).resume(()) {
GeneratorState::Yielded(n) => Some(n),
_ => None,
}
})
}

fn main() {
let one_two_three = || {
yield 1;
yield 2;
yield 3;
};
for n in iter_from_generator(one_two_three) {
println!("{n}");
}
}