Advantages to implementing `FusedIterator` on non-public type

help
1

For an iterator that I'm implementing and is strictly internal, is there any advantage to implementing FusedIterator? I don't ever call fuse, nor do I rely on it in any way. I don't believe the standard library uses specialization for anything on this, but I could be wrong.

Edit: On second thought, the standard library can't use specialization here because it's not an unsafe trait, so any optimization based on it would be unsound…

2

I'd say that it depends. If the type behaves like a fused iterator and you need to rely on this fact, you should implement it, since it nicely documents this iterators property.
If the iterator does only incidentally behave this way and you don't rely on this property, it may not be worth the extra impl block.
On the other hand, I'd always implement it for types which are exported by a library, because

This trait should be implemented by all iterators that behave this way because it allows optimizing Iterator::fuse().

So I'd implement it if, and only if

  • I'd rely on the fact that the iterator is fused, even if it's only used internally, or
  • If the iterator has any chance of one day being exported from the library.
3

Zero chance of it ever being exported. My post wasn't 100% clear, when I say "advantages" I was referring to technical advantages, such as the possibility of optimization.

4

If you use the iterator internally with standard library tools, which use Iterator::fuse, then, yes, you could benefit from optimizations.
If you just use the iterator in a for loop, then no, there's no benefit in implementing it.

Edit FWIW:

~/Projekte/rust/library> grep -rE '\.fuse\(|::fuse\('
alloctests/benches/vec.rs:                .fuse()
std/src/sys/pal/unix/conf.rs:    let mut parsed_ints = version.split('.').map(str::parse::<usize>).fuse();
core/src/iter/traits/marker.rs:/// that behave this way because it allows optimizing [`Iterator::fuse()`].
core/src/iter/traits/marker.rs:/// you need a fused iterator. Instead, you should just call [`Iterator::fuse()`]
core/src/iter/traits/iterator.rs:    /// let mut iter = iter.fuse();
core/src/iter/adapters/fuse.rs:    /// This is equivalent to `I::default().fuse()`[^fuse_note]; e.g. if
core/src/iter/adapters/flatten.rs:        FlattenCompat { iter: iter.fuse(), frontiter: None, backiter: None }
coretests/tests/iter/adapters/fuse.rs:    let i = it.fuse().fold(0, |i, &x| {
coretests/tests/iter/adapters/fuse.rs:    let i = it.fuse().rfold(xs.len(), |i, &x| {
coretests/tests/iter/adapters/fuse.rs:    let i = it.fuse().fold(0, |i, x| {
coretests/benches/iter.rs:    (0i64..1000000).fuse()
coretests/benches/iter.rs:    (0i64..1000000).chain(0..1000000).fuse()
coretests/benches/iter.rs:            .fuse();
~/Projekte/rust/library>

So I guess only Iterator::flatten() would benefit from this.

5

Not every possible optimization has unsoundness as a consequence. Some might merely produce incorrect results.

6

That's effectively what I'm doing, just mapping and collecting afterwards.

True. I'm thinking from my perspective as what the standard library tends to do (such as TrustedLen

7

well you were wrong actually.
this is pretty to be fair, but they did do it