3 ms·

Are you familiar with `core::other::from_fn`[1]. This allows converting from `impl FnMut() -> Option<T>` to `impl Iterator<Item = T>`. I recognise that these a

Are you familiar with `core::other::from_fn`[1]. This allows converting from `impl FnMut() -> Option<T>` to `impl Iterator<Item = T>`. I recognise that these aren't strictly generators - you need to do your own state tracking. However, this does make it easier to do that ad-hoc. I believe there is some work in the ecosystem abusing `async` to make fake generators, although I haven't used any of them. [1]: https://doc.rust-lang.org/stable/core/iter/fn.from_fn.html https://doc.rust-lang.org/stable/core/iter/fn.from_fn.html

cropcirclbureau 4y ago
> `async` to make fake generators. Genawaiter[0] is one of them. [0]: https://github.com/whatisaphone/genawaiter https://github.com/whatisaphone/genawaiter
- estebank 4y ago
  There's also an effort to get generators into the stable language, but it is currently gated on multiple open questions on the async iteration story, including what traits are to be involved (will it be `trait AsyncIteratorItem`? will it wait until GATs and/or async fn in traits and "keyword generics"/"maybe async" functions?), but you can see some explorations of the syntax aspect at https://github.com/estebank/iterator_item/ https://github.com/estebank/iterator_item/ The proc-macro is written in such a way that it tries to parse as much as possible, so that you can try things out mixing and matching from the different alternatives that I've thought of: https://github.com/estebank/iterator_item/tree/master/tests https://github.com/estebank/iterator_item/tree/master/tests Like for example: fn foo() => i32 { for n in 0..10 { yield n; } } fn* foo() -> i32 { for n in 0..10 { yield n; } } gen foo() -> i32 { for n in 0..10 { yield n; } } fn* foo() yield i32 { for n in 0..10 { yield n; } } One thing I love about these is how trivially easy it is to turn an Iterator<Item = Future<Output = T>> into an AsyncIterator<Item = T>: https://github.com/estebank/iterator_item/blob/b79d7b496687b1a0f995bf16ca6482f37061dbca/tests/merge_overlapping_intervals.rs#L328-L335 https://github.com/estebank/iterator_item/blob/b79d7b496687b... async fn* into_stream(input: impl Iterator<Item = Interval>) yields Interval { for i in input { yield i; } }
heavyset_go 4y ago
I'm aware of it, I just find it awkward for some tasks that would be easily expressed using generators in Python or JavaScript.

cropcirclbureau 4y ago

> `async` to make fake generators. Genawaiter[0] is one of them. [0]: https://github.com/whatisaphone/genawaiter https://github.com/whatisaphone/genawaiter

estebank 4y ago
There's also an effort to get generators into the stable language, but it is currently gated on multiple open questions on the async iteration story, including what traits are to be involved (will it be `trait AsyncIteratorItem`? will it wait until GATs and/or async fn in traits and "keyword generics"/"maybe async" functions?), but you can see some explorations of the syntax aspect at https://github.com/estebank/iterator_item/ https://github.com/estebank/iterator_item/ The proc-macro is written in such a way that it tries to parse as much as possible, so that you can try things out mixing and matching from the different alternatives that I've thought of: https://github.com/estebank/iterator_item/tree/master/tests https://github.com/estebank/iterator_item/tree/master/tests Like for example: fn foo() => i32 { for n in 0..10 { yield n; } } fn* foo() -> i32 { for n in 0..10 { yield n; } } gen foo() -> i32 { for n in 0..10 { yield n; } } fn* foo() yield i32 { for n in 0..10 { yield n; } } One thing I love about these is how trivially easy it is to turn an Iterator<Item = Future<Output = T>> into an AsyncIterator<Item = T>: https://github.com/estebank/iterator_item/blob/b79d7b496687b1a0f995bf16ca6482f37061dbca/tests/merge_overlapping_intervals.rs#L328-L335 https://github.com/estebank/iterator_item/blob/b79d7b496687b... async fn* into_stream(input: impl Iterator<Item = Interval>) yields Interval { for i in input { yield i; } }

heavyset_go 4y ago

I'm aware of it, I just find it awkward for some tasks that would be easily expressed using generators in Python or JavaScript.