<p>I've written my first C# iterator today. Woohoo.</p>

<p>Interestingly, it has side effects. My iterator filters out invalid files from a directory and returns a sequence of valid files to process. Wheneve it encounters an invlaid file, it moves it to another directory.</p>

<p>I tried implementing it as a LINQ query, but really don't like the fact that the predicate for the where clause has side effects. That's a definite smell.</p>

<p>I could implement it explicitly, looping over all files and handling the good or the bad in turn, but it's not very elegant. A better solution is to split it into two lists (good and bad) and process each in turn.</p>

<p>But then I remembered iterators. And I've now got an iterator that yields the valid files and handles (moves) the invalid ones.</p>

<p>So, my question is this: is it a bad idea for an iterator to have side effects such as this? Am I hiding too much functionality in an iterator?</p>

I'd say it's
generally
a bad idea to have side-effects in an iterator, but it's not a complete no-no. If you have side-effects, it makes it hard/impossible for callers to work in a purely functional way. This may or may not be a problem depending on your use case.
I suggest you have two ways of getting the iterator - one which has the side-effect (which is presumably an optimisation, basically) and one which doesn't (slower, but simpler to reason about). This could just be by passing a flag into the method, or having two methods named differently.