repeat_with() can return Iterator + Copy

[dohse]

I tried this code:

let mut i = 0;
let iterator = repeat_with(move || {
    i += 1;
    i
});
let _ = iterator.take(1);
let _ = iterator.take(1);

I expected to see this happen:

This should fail to compile with an error like "use of moved value: iterator"

Instead, this happened:

It compiles and creates a copy of the iterator.

Meta

rustc --version --verbose:

rustc 1.89.0 (29483883e 2025-08-04)
binary: rustc
commit-hash: 29483883eed69d5fb4db01964cdf2af4d86e9cb2
commit-date: 2025-08-04
host: x86_64-unknown-linux-gnu
release: 1.89.0
LLVM version: 20.1.7

[asquared31415]

this impl exists (and has existed since 1.28 stable)

impl<F> Copy for RepeatWith<F>
where
    F: Copy,

F: Copy holds as long as the function holds only Copy state (or no state).

I think this is another unfortunate iterator design oversight like the Range situation (which is the opposite problem) but cannot be fixed without breaking changes.

[Hayden602]

I personally don't think this is a bug.

#[derive(Copy, Clone)]
#[stable(feature = "iterator_repeat_with", since = "1.28.0")]
pub struct RepeatWith<F> {
    repeater: F,
}

The RepeatWith struct using the Copy attribute has clear syntactic boundaries, and using zero-cost Copy provides better performance.

Think about it - without the Copy attribute, the code would look like:

let _ = iterator.clone().take(1);
let _ = iterator.clone().take(1);

That feels a bit ugly：）

[theemathas]

@haidong-602

• I don't know what you mean by "clear syntactic boundaries".
• For types that implement both Copy and Clone, cloning usually is equally as efficient as copying.
• Requiring the explicit clone makes it clearer that the intended behavior is to "restart the iterator from the beginning", not "continue where we last stopped".

[Hayden602]

This is a demo of a performance benchmark comparison ：

pub fn main() {
	let mut i = 0;
	let iterator = repeat_with(move || {
	i += 1;
	i
	});

	let start = Instant::now(); 
	for _ in 0..1_000_000 {
		let _ = iterator.clone().take(1);
	}
	let clone_time = start.elapsed();

	let start = Instant::now();
	for _ in 0..1_000_000 {
		let _ = iterator.take(1);
	}
	let copy_time = start.elapsed();
	
	println!("Copy time: {:?}", copy_time);
	println!("Clone time: {:?}", clone_time);
	println!("Clone time is {}x copy time ",
		clone_time.as_nanos() as f64 / copy_time.as_nanos() as f64);
}

In my system, the result is:

Copy time: 7.611629ms
Clone time: 9.028949ms
Clone time is 1.1862045562126058x copy time 

I still don't know why clone takes more time, but regarding this issue, the advantage of copy is obvious.

[theemathas]

@Hayden602

• You have to run the measurement in release mode (cargo run --release) for meaningful measurements.
• You did not use std::hint::black_box, so the loops can be entirely optimized out.
• Sometimes it matters which thing you do first. So you should measure both with cloning before copying, and copying before cloning.

[Hayden602]

@theemathas
You are correct. Thank you. Following the steps you said, I retested, and the time taken does indeed depend on the order of copy/clone execution and the actual time difference is very minimal in release.

If this is an issue, Is removing the Copy operation very costly?

[hanna-kruppe]

The “cost” of removing derive(Copy) from this type is that it’s a breaking change: people’s code may stop compiling.