This code cannot be compiled fn main() { let r1 = 0..10; for x in r1 { println!("{}", x); } println!("{}", r1.len()); } ok, r1 is moved into another reference owned by the for loop...but has this to happen? Why cannot the for loop refers to the original reference? Thx. …

You could call it a design flaw with the current Range implementation: Derive Copy for std::ops::Range and RangeFrom by SimonSapin · Pull Request #27186 · rust-lang/rust · GitHub I don't know if this can ever be fixed. For now, you have to explicitly clone the range (which is cheap): fn main() { …

This happens because the for loop calls into_iter on r1, which takes ownership of it. There are no references here, only moves. What you are suggesting wouldn't work with shared references, because iterators must be mutable to update their state when next() is called. Thus you need to write this if…

Ah, good point. Depending on what you want to happen with your iterator, the piece of code that skysch posted and the piece of code that I posted do not do the same. skysch's prints "0" as the length of the range after the loop and mine prints "10". So which of these variants you should use depends…

Move into for loop

Rejkland April 21, 2020, 4:48pm 5

Ah, so "into_iter" is responsible of ownership... ok, coming from other languages it sounds quiet interesting

thx

Topic		Replies	Views
For loops and ownership	5	13326	May 2, 2015
Ownership in iterator	5	3885	August 23, 2022
Any way to use `&Range` for `for` loops? help	2	523	November 12, 2019
Use of moved value	2	2622	October 13, 2017
Is it possible to take ownership of data back from a for loop once the loop completes help	17	6892	June 28, 2020

Move into for loop

Related topics