Bug 4405 – all function - returns whether predicate is true for all elements in a range
Status
RESOLVED
Resolution
FIXED
Severity
enhancement
Priority
P2
Component
phobos
Product
D
Version
D2
Platform
Other
OS
Linux
Creation time
2010-06-28T20:19:00Z
Last change time
2012-07-19T00:06:58Z
Assigned to
andrei
Creator
issues.dlang
Comments
Comment #0 by issues.dlang — 2010-06-28T20:19:42Z
Two very useful functions to have would what could be called any() and all(). They are, in a sense the || and && of a predicate against all elements a range. any() would take a predicate and a range and return whether any element in that range satisfied the predicate, shortcutting if it found one. all() would take a predicate and a range and return whether all elements in that range satisfied the predicate, shortcutting if it found one which didn't.
std.algorithm currently has canFind(), which is effectively any. One of its versions takes a predicate and a range and returns whether any of the elements satisfies the predicate. So, we basically have any() albeit by a different name and with the original intent of returning whether a particular element could be found in a range. Its definition is flexible enough that it does the job.
However, we have no function which would be all(). You can get similar behavior with various functions, but none of them take a predicate and return whether all elements of a range satisfy the predicate. The closest at present would be to use the negation of the predicate with canFind(). But not only is that like having to use || with ! to implement && (which while possible is rather annoying and often forces you to make your logic less clear), but it's likely to be less efficient to since you may have to wrap one predicate in another to get its negation. There may be other implementation details which affect efficiency as well, though I can't think of any off the top of my head at the moment.
In any case, it would be highly desirable if an all() function were added to std.algorithm.
Comment #1 by andrei — 2010-06-28T20:26:42Z
I prefer any() to canFind(). I agree that all() would be a good addition.
Comment #2 by issues.dlang — 2010-06-28T21:20:24Z
I'd love any() since it's nice and clear. It's just that as far as I can tell, the version of canFind() which takes only a range (along with the predicate) is exactly what any() would do. There may a difference, but I don't know what it would be. But even if there isn't, it wouldn't hurt my feelings any to have any() on top of canFind(). It just seemed likely that someone would complain that it was cruft to have any() when canFind does exactly what any() would do. I would prefer an explicit any() though, since it would be clearer in code what you intended to do.
Comment #3 by andrei — 2010-06-28T21:38:10Z
I think I'll define any() to replace canFind and will slowly deprecate canFind.
Comment #4 by issues.dlang — 2010-06-29T01:51:05Z
Actually, while I'd love to have any(), I do think that having canFind() would make sense so long as it has versions of it which don't match any(). That is, only the most general version of canFind() - the one that only takes a Range (and of course the predicate) - matches up with any(). The other versions of canFind() - as well as canFindSorted() - would definitely be nice to have in addition to any(). If anything, I'd like to see a version of canFind() to match each version of find() - the most glaring hole at the moment being the version that takes a range of needles. There's lots of code where having canFind() be the same as find() would make good sense and be more clear to the programmer.
I do think that it's a good idea to have any() separate from that, and perhaps the version of canFind() which only takes the predicate and the range should be removed, but I do think that it would be a loss to get rid of the other versions of canFind(), and it would be rather odd to rename the other versions of canFind() any().
So, I'd vote to add any() and all(), and then remove the version of canFind() which only takes the predicate and the range.
That way, we have canFind() to match find() where it makes sense, and we have the more general any() and all() where they make sense.
Comment #5 by bearophile_hugs — 2011-02-07T15:08:28Z
I have written a duplicated enhancement request: bug 5544
There I have asked an all() and any() that allow to write code as this:
import std.algorithm;
void main() {
auto items = [1, 7, 22];
bool r1 = all!q{a % 2}(items);
assert(!r1);
items = [1, 7, 21];
bool r2 = all!q{a % 2}(items);
assert(r2);
}
Instead of:
import std.algorithm;
void main() {
auto items = [1, 7, 22];
bool r1 = reduce!q{a && b}(true, map!q{a % 2}(items));
assert(!r1);
items = [1, 7, 21];
bool r2 = reduce!q{a && b}(true, map!q{a % 2}(items));
assert(r2);
}
Comment #6 by bearophile_hugs — 2011-02-07T15:08:53Z
*** Issue 5544 has been marked as a duplicate of this issue. ***