D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 4405 - all function - returns whether predicate is true for all elements in a range
Summary: all function - returns whether predicate is true for all elements in a range
Status: RESOLVED FIXED
Alias: None
Product: D
Classification: Unclassified
Component: phobos (show other issues)
Version: D2
Hardware: Other Linux
: P2 enhancement
Assignee: Andrei Alexandrescu
URL:
Keywords:
: 5544 (view as issue list)
Depends on:
Blocks:
 
Reported: 2010-06-28 20:19 UTC by Jonathan M Davis
Modified: 2012-07-19 00:06 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Jonathan M Davis 2010-06-28 20:19:42 UTC
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 Andrei Alexandrescu 2010-06-28 20:26:42 UTC
I prefer any() to canFind(). I agree that all() would be a good addition.
Comment 2 Jonathan M Davis 2010-06-28 21:20:24 UTC
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 Andrei Alexandrescu 2010-06-28 21:38:10 UTC
I think I'll define any() to replace canFind and will slowly deprecate canFind.
Comment 4 Jonathan M Davis 2010-06-29 01:51:05 UTC
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 bearophile_hugs 2011-02-07 15:08:28 UTC
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 bearophile_hugs 2011-02-07 15:08:53 UTC
*** Issue 5544 has been marked as a duplicate of this issue. ***
Comment 7 Jonathan M Davis 2012-01-20 23:25:13 UTC
https://github.com/D-Programming-Language/phobos/pull/344
Comment 8 Brad Anderson 2012-07-19 00:06:58 UTC
This has been merged.