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

It would be nice, but realistically, that's not how `all` or `any` would likely be used. They'd be used as conditions in if statements. If you really wanted to find an element that did or didn't match the predicate, you'd use something like `find` or `countUntil`. If there were no additional overhead, then it would be fine with me to have them return an index or range, but there _is_ overhead. That's one of the reasons that we have `canFind` in addition to `find`.

As for `all` being a step forward or not, I think that it's a definite step forward - albeit not a huge one. Being forced to use `not` tends to lead to much more verbose - are therefore harder to read - code. So, I think that when dealing with functions that are likely to be quite commonly used and which take a boolean predicate, there's definite value in having two versions of the function. Functional languages certainly tend to. And `all` and `any` are probably _the_ prime example of such functions.

So, I'd argue that we should add `all`, and rename the overload of `canFind` which just takes the predicate and the range to `any` (either that or create a wrapper function, though it's probably better to rename it). An alias would be bad IMHO, since then you could do stuff like `any(range, elem)`, which arguably doesn't make a lot of sense. But I suspect that a lot of the programmers who use `canFind` as `any` or `all` would be quite willing to deal with the resulting code breakage anyway, since it would make their code clearer.