Understanding FusedIterator

I understand what the semantics of FusedIterator is (once None is returned, it will only yield None on further iterators), but I don't know what its used for.

I'm working on a collection which has an draining iterator that can be implemented in two different ways, and I'm not sure which to choose -- so I'm fishing around to see if there are any benefits to one or the other. The implementation difference would express itself in that one way would make it explicitly FusedIterator compatible, while the other would make it explicitly FusedIterator incompatible.

What would be a typical use-case for a FusedIterator? Are there any general reasons to strive for implementing it (when possible) for collection iterators?

FusedIterator is merely a marker that ensures at the type system level that None will never be followed by Some. Some iterator adapters need this for logical consistency, and it is generally the behavior that people expect from well-behaved iterators. Starting to get Some after None is technically valid behavior for a non-fused iterator, but it still raises eyebrows, and rightfully so. So if you can implement your iterator in a way that it's fused, you should.

1 Like

Since fused is the typical behavior, I wanted to explain a use case from the other direction...

I threw together a generic non-fused iterator which given another iterator returns None until some count is reached... Rust Playground

This could probably be better implemented (using empty, repeat, chain, etc)... But I have used things like this on occasion when implementing some sparse data structures, where you can use chains of None's standing in for sparse gaps in the data structure...

but it really is a special case when you want to iterate over None, otherwise nobody ever got fired for implementing fused iterator.

2 Likes