Should we add `Iterator::none`?

language design
21

These implementations are not correct.

    let v = vec![2, 1];
    let r = v.iter().any_not_all(is_odd);
    assert_eq!(r, true); // panics

    let v = vec![1, 2];
    let r = v.iter().all_or_none(is_odd);
    assert_eq!(r, false); // panics

That's because the any and all methods consume items from the iterator, so when one returns early, the other only checks the remainder of the elements.

Normally that would be an argument in favour of inclusion, but… how often does one need all_or_none or any_not_all, really? I don't see any good use case for it. And the others can already be succinctly expressed in terms of !, or if you insist, Borat conditions. They aren't any more expressive, clear or readable than that, and I'd argue they are less: I'd be less confident reading code that freely interchanges those combinators, because I'd have to memorise them all to be sure they perform as they are named (hello, #define FIVE 42). If they aren't there, not only there'd be less to memorise, but the logical structure of the condition would be much more apparent, making it easier to notice how code could be refactored.

Where is @H2CO3 when you need him?

(I know, the real @H2CO3 was the friends we made along the way… Wait, wrong cliché.)

4 Likes