Conversation

frens, is there a way to express `(&mut iterator).take(161)` in a different way?

(For those who are curious, the above gives me an iterator over the next 161 items without that consuming the iterator. That means that after that scope, I can still work with the iterator.)

2
0
0

I think it's fine, but perhaps there is a method I don't know about that expresses the matter in a more.. explicit way?

2
0
0

@ma3ke like there might be a method wrapping it somewhere that abstracts over it, but that's literally how you keep ownership while granting mutable access in the language and there are iterator instances to support it. you'll find the same in async sometimes.

1
0
0
@ma3ke The best alternative (which does not really do the same) would probably be Iterator::next_chunk, though that is nightly only. And may blow your stack if it is some big items.

https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.next_chunk
1
0
1

@erk yes, I love next_chunk a lot! for other use cases it would fit the bill even better than take, but in my current case I only know how many lines are coming my way at runtime.

moreover, I'm targeting stable for the thingy I'm currently working on.

0
0
1

@ma3ke clippy suggests .as_mut() for the .take() combinator for Read impls

2
0
0

@hipsterelectron
good one, may end up doing that little .as_mut() in the end.

0
0
0

@ma3ke the zip crate casts to an &mut dyn Read to do this in one spot

0
0
0