`missing_iterator_fold`

[Philippe-Cholet]

What it does

Lints implementations of core::iter::Iterator that do not specialize the fold method.

Advantage

• Methods that consume the entire iterator (for_each, count, ...) rely on fold by default and would benefit from fold being specialized.
• Adaptor iterators might use fold (or related methods) for their own usage and would benefit as well.

Drawbacks

Specialize it may not be faster than the default behavior.

Example

struct Iter(u8);
impl Iterator for Iter {
    type Item = u8;
    fn next(&mut self) -> Option<Self::Item> {
        todo!()
    }
}

Could be written as:

struct Iter(u8);
impl Iterator for Iter {
    type Item = u8;
    fn next(&mut self) -> Option<Self::Item> {
        todo!()
    }
    fn fold<B, F>(self, init: B, f: F) -> B
    where
        F: FnMut(B, Self::Item) -> B
    {
        todo!()
    }
}

[Philippe-Cholet]

@rustbot claim

[Philippe-Cholet]

Hi I'm a member of rust-itertools. The idea originated there: rust-itertools/itertools#755

I think it would be beneficial to have other lints as well ([try_][r]fold, size_hint mainly) so this is only the first one.
A single LateLintPass would be needed for all of them.

[Philippe-Cholet]

After discussion on zulip and some reflexion, those lints (if wanted) should at least be part of the same lint pass as missing_trait_methods. Alternatively, missing_trait_methods could be configurable in clippy.toml. Have multiple lints would be more flexible but I understand the reluctance expressed.

EDIT: I will soon make a PR to make missing_trait_methods configurable.