dsimcha/phobos — comment on commit 4c1177cced750d6e16622ffcc5c4b114f9f06808
File:  line 0
By dsimcha:

Of course this is a pretty minor step forward. It's just that IMHO wanting t find out efficiently whether some predicate is true for all elements of a range is so common that it needs to be both trivial and readable to code. I say "efficiently" because to me, it's a no-brainer that `all` needs to stop early instead of returning the length of the range. Using something like:

assert(!canFind!(not!isOdd)([1, 3, 5, 7, 9])); // (1)

// instead of
assert(all!isOdd([1, 3, 5, 7, 9])); // (2)

is a bad idea, but more because it's a pain to read than because it's a pain to write. If you saw (1) in a piece of code you'd have to think about what the double negation implied. If you saw (2) you would know immediately what the point was, with zero thought. Most things aren't worth optimizing this much, but IMHO `all` is so common that this is justified.

As far as `any`, what good would the 1-based position do? If `any` is false, then we definitely want to return something that evaluates to false, which would mean we'd need to return 0. If `any` is not false, then IMHO returning a one-based index just adds confusion. I can't stand the idea that this assert could fail because of the 1-based indexing:

assert(pred( someRange[ any!pred(someRange) ] ));