3 ms·
I think the thing is that because the IntoIter consumes the collection, you are right that it is turning it "into" an iterator... I guess. But for me that's no
by mikekchar 6y ago
I think the thing is that because the IntoIter consumes the collection, you are right that it is turning it "into" an iterator... I guess. But for me that's not the intent of what I'm doing. If I use iter() or mut_iter(), I'm also getting an iterator. The fact that it doesn't consume the collection is not the thing I care about. I don't program thinking "Oh, I want to consume this collection when I create the iterator, so let's use into_iter()". I think, "Oh, I want to get owned objects out of the iterator. As a side effect of that, it will consume the collection". For me, anyway, it's just a seriously backwards way of saying what you want.
I find that, similar to my experience with Rails (and Rails developers), once you've drunk the Kool aide, it starts to make sense. You are fluent in the language that is being used and you can't think any other way about it. Even if it is awkward, it seems normal and obvious. But when you first approach it, it can be hard to acquire the idea.
- wtetzner 6y agoI could see that. It was a little confusing to me too. At first I couldn't figure out why anyone would want into_iter(). Didn't realize it returned owned objects. Now that I think about it, how does into_iter() work on a Vec? Is it just copying the data out of the Vec anyway? Because the data in a Vec is allocated on the heap, so how can you get an owned object that isn't just a reference (pointer) to the heap memory without copying? If that's the case, is the only benefit of into_iter() that you don't have to explicitly deref and copy the items?