rust - Why doesn't ops::Range<T> implement Copy, even if T is Copy? -

recently, wanted write type holding parameters 3d projection:

use std::ops::range;  #[derive(clone, copy)] struct camproj {     /// near , far plane     proj_range: range<f32>,     /// field of view     fov: cgmath::rad<f32>,     // `rad` derives `copy`     /// width divided height     aspect_ratio: f32,        } 

however, got error:

error[e0204]: trait `copy` may not implemented type  --> <anon>:3:21   | 3 |     #[derive(clone, copy)]   |                     ^^^^ ... 6 |         proj_range: range<f32>,   |         ---------------------- field not implement `copy` 

so apparently, range<t> never implements copy, if t copy, f32 is. why that? thought range<t> pair of ts? surely implement copy?

because range<t> used iterator, , having iterators copy was discovered footgun. one specific example had thinking iterator advanced, when in reality copy advanced:

for x in {  // *copy* of iterator used here     // .. }  match it.next() {  // original iterator used here     // .. } 

another example:

fn main() {     let stream = "hello, world!".chars().cycle();     _ in 0..10 {         let chunk: string = stream.take(3).collect();         println!("{}", chunk);     } } 

and prompted question: using same iterator multiple times in rust

it believed having iterators explicitly copied via clone helped prevent these cases

---

specifically re-adding copy range was proposed , rejected. potential workaround suggested:

range fields public, can repack them copyable tuple (or equivalent) @ constructor/function boundary

see also:

• why iterators not copyable?
• re-using range iteration