It would be great to have these functions, which would behave similarly to the once / once_with and repeat / repeat_with functions, except they would iterate a fixed number of times (given by a usize) instead of just once/infinitely.
So, like repeat(...).take(n)? This doesn't seem useful to me.
I've wanted this myself a number of times.
The problem with repeat(...).take(n) is that it doesn't implement ExactSizeIterator or DoubleEndedIterator.
Ok, that seems like a good reason to do this.
Perhaps an InfiniteIterator trait could be added to help in these cases? That way, repeat(x).take(n) is always ExactSizeIterator.
The problem with
repeat(...).take(n)is that it doesn't implementExactSizeIteratororDoubleEndedIterator.
Exactly.
Perhaps an
InfiniteIteratortrait could be added to help in these cases? That way,repeat(x).take(n)is alwaysExactSizeIterator.
I believe this requires mutually exclusive traits.
(0..20).map(|_| ...) is how I've always done this; it works well, is fairly obvious after looking at it, and I'm confident I'll never reach for an import since this exists. Maybe we can document this pattern instead of adding more types and functions?
@Mark-Simulacrum Sure, that's the obvious alternative... but has anyone profiled that vs. a more direct approach? Also, see the above comment vs. issues with trait implementations.
Ranges are, in fact, double ended, exact, and TrustedLen. We probably should add Fused to that (looks like it's just an accidental omission). Map preserves all of those.
Performance wise, I'm not sure. I suspect you can't really do better than Range because you basically are just doing what it is...
Possibly. I'd still be interested in benchmarks.
Triage: it's been a year. If anyone is interested in implementing this and doing benchmarks, please send in a pull request if it is indeed better than the map. Thanks.
Most helpful comment
Perhaps an
InfiniteIteratortrait could be added to help in these cases? That way,repeat(x).take(n)is alwaysExactSizeIterator.